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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
