-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Changed Gradle project templates to use the platform BOM properties, … #5012
Changed Gradle project templates to use the platform BOM properties, … #5012
Conversation
While the failed tests are not currently relevant and could be ignored, I'm planning to review and fix them. |
54b85d3
to
73e861a
Compare
One of the maven projection generating tests will fail because I thought removing managed dependencies from the descriptor was a good idea. I'll fix it a bit later. |
devtools/gradle/src/main/java/io/quarkus/gradle/AppModelGradleResolver.java
Outdated
Show resolved
Hide resolved
devtools/gradle/src/main/java/io/quarkus/gradle/GradleDependencyArtifact.java
Show resolved
Hide resolved
…made Gradle list and add extensions commands to use the correct platform descriptor, enhanced JSON descriptor resolver to determine the JSON artifact corresponding to the specified BOM coords, enhanced Gradle AppModelResolver impl, fixes related to resolution of the latest platform version
73e861a
to
342fc21
Compare
ConnectionToReplicaSetTest>MongoWithReplicasTestBase.startMongoDatabase:56->MongoWithReplicasTestBase.initializeReplicaSet:90 » MongoTimeout Isn't related. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall looks good; i think we should cleanup the property names/references but we can do that in a follow up PR as it is following yet another format in the mvn generated projects.
final QuarkusPlatformDescriptor platform = QuarkusJsonPlatformDescriptorResolver.newInstance() | ||
.setArtifactResolver(extension().resolveAppModel()) | ||
.setBomVersion( | ||
getRequiredProperty(props, "quarkusPlatformBomGroupId"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these shuld be something like quarkus.platform.bom.group-id
to match naming style use elsewhere.
i.e. quarkus.version as used in mvn.
maybe just quarkus.platform.group-id to make it shorter; the bom is implied anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No objections changing the style. We've been using quarkusVersion in gradle.properties, so I simply followed that.
As to quarkus.platform.group-id
w/o the bom
in it, possibly ok, however we might want to support quarkus.platform.json.group-id
at some point. QuarkusJsonPlatformDescriptorResolver for example already includes such a property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm gonna merge it in this state though. Adjusting the style could be done as a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think camel case is the usual Gradle style. At least I saw that used a lot in Gradle files.
…made Gradle list and add extensions commands to use the correct platform descriptor, enhanced JSON descriptor resolver to determine the JSON artifact corresponding to the specified BOM coords, enhanced Gradle AppModelResolver impl, fixes related to resolution of the latest platform version
@maxandersen @gastaldi I think this PR is good enough for Gradle support. I tested it with the custom built universe which includes Camel too. Specifically, it's about list and add extensions.
QuarkusJsonPlatformDescriptorResolver class is probably going to be used in a similar manner in the Maven case. Except that I'll still need to fallback to the classpath discovery of resources in case we are offline.