Align archetype generated pom.xml to to quarkus:create #10836
Conversation
|
@gsmet This is a regression in 1.6.0. Users could fix it themselves but they would first need to know what to change in PS: I described the workaround: #10826 (comment) |
Come to think of it, the current very strict check is denying the users the possibility to restructure their |
| <surefire-plugin.version>3.0.0-M5</surefire-plugin.version> | ||
| <maven.compiler.parameters>true</maven.compiler.parameters> | ||
| <quarkus.version>999-SNAPSHOT</quarkus.version> | ||
| <assembly-plugin.version>3.1.0</assembly-plugin.version> |
There was a problem hiding this comment.
Defining version properties for some plugins but directly setting versions for other plugins seemed inconsistent, so I introduced this property.
Not sure why it has to be 3.1.0, though. The latest version is 3.3.0.
|
Hey guys, sorry, I was in PTO. Maybe we need to change the check which seems a bit too strict.. the idea is that our tooling should only work when the pom.xml contains a valid Quarkus bom (cc @aloubyansky) |
|
I'm a bit worried about the usage of the quarkus-universe-bom in the core project. I don't really see a better solution though. Maybe @aloubyansky would have some input. |
|
@ia3andy I'd suggest to adjust the check in a sperate PR. |
no problem and thanks!! I am waiting for @aloubyansky take on it, and could provide a PR. |
Related to quarkusio#10836, Fixes quarkusio#10826
|
FYI, azure functions does not support Java 11. |
| @@ -6,10 +6,19 @@ | |||
| <artifactId>${artifactId}</artifactId> | |||
| <version>${version}</version> | |||
| <properties> | |||
| <compiler-plugin.version>3.8.1</compiler-plugin.version> | |||
| <maven.compiler.parameters>true</maven.compiler.parameters> | |||
| <maven.compiler.source>11</maven.compiler.source> | |||
There was a problem hiding this comment.
azure functions does not support Java 11.
|
I worry that you have not testesd these changes. For instance, azure functions does not support Java 11. Much of this is my fault for not having automated testing of the archetypes. |
Related to quarkusio#10836, Fixes quarkusio#10826 As soon as the descriptor is resolved, we should be ok in 99.9% of the case..
Related to quarkusio#10836, Fixes quarkusio#10826 As soon as the descriptor is resolved, we should be ok in 99.9% of the case..
|
@patriot1burke it's under control here: #10845 . |
Related to quarkusio#10836, Fixes quarkusio#10826 As soon as the descriptor is resolved, we should be ok in 99.9% of the case..
Yes and no. 😉 That's also why I highlighted this notable change in the PR description. But as @gsmet already said: It's under control! 🙂 |
Fixes #10826, at least for the creation of new projects.
Currently this block does not match for the archetype generated pom.xml: https://github.com/quarkusio/quarkus/blob/master/independent-projects/tools/devtools-common/src/main/java/io/quarkus/devtools/project/buildfile/MavenBuildFile.java#L81-L83
AFAICT, this is a regression caused by a larger refactoring: 97f9981 (/cc @ia3andy).
Since I did/do not question this extended check, I aligned all four archetype pom.xml files to what
quarkus:createis doing.Some notable and maybe debatable "side effects":
quarkus-universe-bomis used instead ofquarkus-bom, so for testing you either need a matching999-SNAPSHOTof universe or you have to define-Dquarkus.platform.artifact-id=quarkus-bom(in conrast,mvn io.quarkus:quarkus-maven-plugin:999-SNAPSHOT:createis generating a1.6.0.Finalproject...)Theoretically we could (additionally?) soften the check. But again, I did not question that for this fix.