jamesfredley commented on code in PR #15467:
URL: https://github.com/apache/grails-core/pull/15467#discussion_r3164049529
##########
grails-doc/src/en/guide/commandLine/gradleBuild/gradleDependencies.adoc:
##########
@@ -60,28 +60,26 @@ dependencies {
Note that version numbers are not present in the majority of the dependencies.
-This is thanks to the Spring dependency management plugin which automatically
configures `grails-bom` as a Maven BOM via the Grails Gradle Plugin. This
defines the default dependency versions for most commonly used dependencies and
plugins.
+This is thanks to Gradle's platform support which automatically imports
`grails-bom` as a managed dependency platform via the Grails Gradle Plugin.
This defines the default dependency versions for most commonly used
dependencies and plugins.
Review Comment:
Updated in 2ca302b. The relevant section in
`grails-doc/src/en/guide/commandLine/gradleBuild/gradleDependencies.adoc` now:
1. Explicitly calls out that the property-override mechanism is a feature of
the new `org.apache.grails.gradle.bom-property-overrides` plugin and links to
https://github.com/gradle/gradle/issues/9160 so readers know it isn't native
Gradle behaviour.
2. Adds a NOTE block describing the resolution side effect you raised: the
plugin participates in Gradle's standard conflict resolution, so when an
artifact is requested at multiple versions Gradle's *highest-version-wins*
picks the version, and the property-override pins what wins after that. This
contrasts with the legacy Spring DM plugin which forced BOM versions
unconditionally and could mask transitive drift. `enforcedPlatform(grails-bom)`
is documented as the escape hatch for stricter behaviour.
3. Also documents how the new plugin can be applied standalone (non-Grails
projects) so the property-override workflow isn't tied to `grails-bom`.
Happy to refine the side-effect wording further after the weekly discussion
- leaving this thread open in case you want to expand on it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
