introduce notion of a platform parent pom.xml

[maxandersen]

Description with introduction of platform the generated app has more than just one version to take care off. quarkus.version AND quarkus.platform.version + various setup that is now generated into every pom.xml we generate.

Implementation ideas suggestion is to make platform publish a matching parent pom which would define these versions + include the repeated plugin mgmt and profiles. would greatly simplify users pom.xml.

Open question is how to handle this in gradle projects.

[maxandersen]

existingn PR for quarkus repo: https://github.com/quarkusio/quarkus/pull/3754 platform poc: https://github.com/aloubyansky/quarkus-platform-poc/tree/master/parent

[aloubyansky]

It's unlikely this one will make it into 1.0. Besides creating the parent in the universe repo, it will also mean updating the project generating templates and then also probably the logic that checks what the target platform is. Since the application pom.xml can have a parent that imports the BOM or import the BOM directly, or have no parent and no BOM. It's not necessarily difficult to do but will certainly take time that we may not have enough before 1.0.

[maxandersen]

we need to update the templates and tools anyways to deal with separate quarkus.version and quarkus.platform.versions anyway.

Not sure what you refer to by "probably the logic that checks what the target platform is" ? wouldn't bom still be referenced by users projects ?

[aloubyansky]

we need to update the templates and tools anyways to deal with separate quarkus.version and quarkus.platform.versions anyway.

For what exactly? quarkus.version is going to be used in the plugin configs. And the BOM version is a specific value at this point. So it kind of works.

Not sure what you refer to by "probably the logic that checks what the target platform is" ? wouldn't bom still be referenced by users projects ?

No, the BOM would be inherited from the parent.

[maxandersen]

For what exactly? quarkus.version is going to be used in the plugin configs. And the BOM version is a specific value at this point. So it kind of works.

to update the used platform version. That is ultimately the only thing users should need to do.

Not sure what you refer to by "probably the logic that checks what the target platform is" ? wouldn't bom still be referenced by users projects ?

No, the BOM would be inherited from the parent.

if we could avoid that things would be simpler imo. then use of parent is 100% optional.

[aloubyansky]

Parent by its nature is a convenience. It's never required. People may want to prefer/be forced to use other parents.

[maxandersen]

well, if we kept the bom reference in user projects for now it wouldn't require the changes you feared would take some time.

but i agree it would be tricky no matter what - but if we don't do this we'll need to at least document how to update...as it is no longer just bumping one thing.

[aloubyansky]

BTW, if you have the parent and import the BOM explicitly in the app's pom, you are going to end up modifying two lines for updating the version. Because properties aren't allowed in parent element.

[maxandersen]

gdammit - that’s why we can't have nice things ;)

[gastaldi]

I'm :-1: to having a parent pom.xml and the main reason is because most enterprise developers already have their own preferred parent pom. Not to mention that child poms will inherit some of its tags (<description>, <scm>, to name a few), which does not make sense at all

[maxandersen]

Challenge is that 80-90% of the generated pom will be pure scaffolding. What is your suggested alternative ?

I'm not a fan either but its apparently not stopping start.spring.io examples to be used. Note, in this case its not about making a generic good parent - its about making it easy to use quarkus in opinionated way.

Gradle's approach is nicer this way as the plugin can do "mix-ins" rather than straight up inheritance.

[gastaldi]

IMHO considering that configuring Quarkus is simply adding dependencies and the Quakus plugin, a parent pom won't help much. What would be interesting though is if we could introduce some POMs that simply transitively resolves to some common extensions (for example, microprofile)

[maxandersen]

have you looked at the generated pom ? its not just dependency adding ;)

[ge0ffrey]

I think most projects don't warrant the use of a parent pom for users, as there can only be one parent. But if Quakus is the basis of the RH portfolio, then it is the exception and it should offer a parent pom, like Spring does. But ideally, the code.quakus.io website allows choosing between "parent pom" and "bom" (with "parent pom" as the default as that generates a pom with half as many lines.)

[maxandersen]

to be clear - code.quarkus.io is just a fancy UI into the quarkus project creator (accessible with mvn too)

Adding a parent bom and bom here would of course technically be possible but I think such option will lead to confusion worse than either doing one or the other.

So we'll need to figure out if there is value enough to have a parent pom.

[Ladicek]

I agree with @gastaldi: users typically already have their own corporate parent POM. In such case, pushing "common stuff" into a parent POM in an example makes the example harder to use / less useful. If the example has everything that one needs to use Quarkus, you immediately see it. If it's pushed out to a parent POM, it's not immediately obvious, and you even need to figure out what exactly from the parent POM is relevant to you and what is an unnecessary detail that had to be in the parent POM so it could be released into Maven Central.

[edeandrea]

I have never been a fan of framework parent poms for the reason @Ladicek mentioned - most organizations will have their own corporate parents. It also doesn't fit the Gradle model. Importing BOMs is more common to both tools and fits within the organization parent pom model.

[ge0ffrey]

I agree that production users will typically use their own corporate parent POM. But during the Getting Started experience of day 1, it would reduce complexity, reducing the churn.