Re: [PR] feat: Replace Spring Dependency Management plugin with Gradle platform + lightweight BOM property overrides [grails-core]

["jamesfredley (via GitHub)" <gi...@apache.org>]

jamesfredley commented on PR #15467:
URL: https://github.com/apache/grails-core/pull/15467#issuecomment-4597774506

   ## Update: merged `8.0.x` + three correctness fixes to the override engine
   
   Brought the branch up to date with `8.0.x` and fixed three real bugs in the property-override feature that a review surfaced. Flagging here because the behavior changes are significant. The PR description has been rewritten to describe current behavior in full.
   
   ### `be2c6af` - merge `8.0.x`
   
   Resolved two conflicts:
   
   - `GrailsGradlePlugin.validateMicronautBom()` - kept the `validMicronautBoms` set (`grails-micronaut-bom`, `grails-hibernate5-micronaut-bom`) from `8.0.x` alongside this PR's explanatory comment.
   - `upgrading80x.adoc` - renumbered the upgrade-guide sections back to a sequential 1-25 (the two branches had collided into duplicate section numbers) and fixed the `§` cross-references.
   
   ### `545b847` - fix: correct BOM property-override edge cases
   
   **1. The deprecated `springDependencyManagement` opt-out had become a silent no-op.** `applyGrailsBom()` only checked `autoApplyBom`, so `grails { springDependencyManagement = false }` no longer suppressed the BOM. That flag is still set by `gradle/grails-extension-gradle-config.gradle` (applied across ~76 in-repo builds, with a comment warning that auto-applying the BOM "causes unexpected version mismatches in the various plugin projects") and is a documented Grails 7 opt-out external users may rely on. The deprecated setter now maps `false` -> `autoApplyBom = false`.
   
   **2. Downgrade overrides silently failed.** Overrides were applied with `eachDependency().useVersion()`. Because `platform()` contributes `require` constraints that stay in the graph, Gradle's highest-version-wins conflict resolution ran *before* the override, so an override **lower** than the BOM default was silently ignored (you asked for `slf4j 1.7.36`, you got the BOM's `2.0.x`, no error). Overrides are now applied as **strict** constraints, so they win in both directions - matching Spring DM, which always forced overrides.
   
   **3. Overriding an imported-BOM property did nothing.** `grails-bom` imports `spring-boot-dependencies` via a `${spring-boot.version}` property reference. The parser resolved imports using the BOM's *default* property values only, so overriding `spring-boot.version` never switched the imported Spring Boot set. `BomManagedVersions` was rewritten to a **two-pass version-diff** model: it computes every managed artifact's effective version with BOM defaults and again with project overrides applied (including to imported-BOM selector versions), and the difference becomes the override set. It now records **all** managed entries (literal versions included), so switching an imported BOM picks up its full managed set, including hardcoded versions; a BOM's direct entries take precedence over imported ones.
   
   Added `GrailsExtensionSpec` and `BomOverrideResolutionFunctionalSpec`. The latter does a **real** resolution against a local Maven repo and asserts (a) a downgrade override wins over the platform constraint and (b) overriding an imported-BOM selector bumps a hardcoded transitively-managed version.
   
   ### `f1c76ac` - docs: align with strict-constraint behavior
   
   `gradleDependencies.adoc` and `upgrading80x.adoc` still described the old soft-override behavior (overrides lose to conflict resolution; use `enforcedPlatform` for stricter behavior). Updated them to state that explicit overrides are strict and always win (including downgrades), while only the BOM's *default* managed versions still participate in conflict resolution.
   
   All affected `:grails-gradle-plugins` tests pass (19 BOM/extension tests, including the new real-resolution spec).
   


-- 
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: notifications-unsubscribe@grails.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org