-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
introduce notion of a platform parent pom.xml #4723
Comments
existingn PR for quarkus repo: #3754 |
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. |
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 ? |
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.
No, the BOM would be inherited from the parent. |
to update the used platform version. That is ultimately the only thing users should need to do.
if we could avoid that things would be simpler imo. then use of parent is 100% optional. |
Parent by its nature is a convenience. It's never required. People may want to prefer/be forced to use other parents. |
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. |
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 |
gdammit - that’s why we can't have nice things ;) |
I'm 👎 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 ( |
Challenge is that 80-90% of the generated pom will be pure scaffolding. I'm not a fan either but its apparently not stopping start.spring.io examples to be used. Gradle's approach is nicer this way as the plugin can do "mix-ins" rather than straight up inheritance. |
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) |
have you looked at the generated pom ? its not just dependency adding ;) |
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. |
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. |
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. |
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. |
I agree that production users will typically use their own corporate parent POM. |
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.
The text was updated successfully, but these errors were encountered: