jamesfredley commented on PR #16073:
URL: https://github.com/apache/grails-core/pull/16073#issuecomment-5144395880
## Updated - the regression is gone and this is ready for review
`e08bb1e815` replaces the local-BOM staging approach entirely. The `*-cli`
regression documented earlier is resolved, because the mechanism that caused it
has been removed rather than adjusted.
**What the branch now does.** The example stops importing
`org.apache.grails:grails-bom` as a Maven BOM artifact and manages its versions
from `dependencies.gradle` instead - already the single source of truth, and
already read by this example for its logback and jackson overrides. `grails {
bom = null }` and `io.spring.dependency-management` both remain, so the
coverage the example exists for is intact: a migrated Grails 7 application
whose versions come from Spring DM rather than the platform. `build.gradle` and
`GrailsRepoSettingsPlugin.groovy` are back to their `8.0.x` state; there is no
local repository and no configuration-time pom generation.
**A second defect was found and fixed along the way.** Spring Boot's BOM is
still imported automatically, and wherever an explicit entry was missing it
silently supplied an *older* version:
| Coordinate | Repo-managed | Was resolving | Now |
|---|---|---|---|
| `groovy-console`, `groovy-json`, `groovy-sql`, `groovy-templates`,
`groovy-xml` | 5.0.7 | 5.0.6 | 5.0.7 |
| `commons-codec` | 1.22.0 | 1.21.0 | 1.22.0 |
| `log4j-api`, `log4j-to-slf4j` | 2.25.5 | 2.25.4 | 2.25.5 |
Fixed by overriding the corresponding Spring Boot version properties from
`dependencies.gradle`. No version literal is hardcoded anywhere and
`dependencies.gradle` is unmodified.
**`verifyDependencyManagementVersions`** was added and wired into `check`,
asserting resolved versions on `compileClasspath` and
`integrationTestRuntimeClasspath`. This exists because every functional check -
cold build, offline build, clean build, integration test, BOM integrity -
passed while those versions were silently wrong. A green build was never
evidence for this class of defect.
The assertion is proven in both directions: it passes as committed, and with
`ext['log4j2.version']` removed it fails with `compileClasspath resolved
org.apache.logging.log4j:log4j-api:2.25.4, expected 2.25.5`. Writing it also
exposed that its first version was keyed by a `GString`, so every lookup
returned null and it was asserting nothing at all - the completeness guard now
makes that failure mode loud.
### Verification
| Check | Result |
|---|---|
| Cold + clean at never-published `9.9.9-SNAPSHOT` | exit 0 |
| Cold + `--offline` | exit 0 |
| Default `8.0.0-SNAPSHOT` | exit 0 |
| `grails-bom` pom | 111 `<artifactId>` entries, all 9 `grails-*-cli` -
matches published |
| `verifyDependencyManagementVersions` | passes; fails on injected drift |
| `integrationTest` | passes |
| `BomPropertyOverridesPluginSpec` | passes |
### Known follow-ups
1. `expectedDependencyVersions` covers the overridden families but omits 11
other explicitly managed coordinates (Ant, Jansi, JLine, Hibernate, Objenesis,
SiteMesh, Spock). Those declarations could be mistyped or removed without the
check noticing. Worth widening.
2. `bomSnapshotNotPublished` in `8.1.x` / `9.0.x` becomes dead configuration
once this merges forward - remove the property and its comment during each
merge-up.
### Trade-off for reviewers to confirm
The example no longer exercises consuming a real Maven BOM artifact through
Spring DM. That path never validated the commit under test - it always resolved
the last published BOM - and Grails 8 applications use the platform BOM. Both
automated reviewers flagged this as the deliberate cost of the change, so it
should be an explicit decision rather than a silent one.
The `BomPropertyOverridesPlugin` coordinate fix
(`grails.core.ROOT:grails-hibernate5-bom:unspecified`) remains in this branch
and is a genuine defect independent of the example; happy to split it into its
own PR if preferred.
--
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]
