jamesfredley opened a new pull request, #15730:
URL: https://github.com/apache/grails-core/pull/15730
## What
Stop maintaining `grails-bom` version pins that duplicate versions already
managed by the `spring-boot-dependencies` BOM (Spring Boot 4.1.0). Where our
pin equals Spring Boot's managed version, the pin is dead weight: it only
blocks free patch/security updates whenever Spring Boot bumps the dependency.
Those pins are removed so the BOM inherits the version from Spring Boot.
Fixes #15674
> Note: the issue was drafted against Spring Boot 4.0.6. This PR re-audits
against the **4.1.0** BOM actually on `8.0.x`, so the SAME/DIVERGENT buckets
differ from the issue (e.g. `commons-lang3` and `byte-buddy` have since
converged with Spring Boot and are now removable).
## Removed (each equal to Spring Boot 4.1.0's managed version)
| Pin | Version | How it's still managed |
|-----|---------|------------------------|
| `byte-buddy` (+ `byte-buddy-agent`) | 1.18.10 | spring-boot-dependencies |
| `commons-codec` | 1.21.0 | spring-boot-dependencies |
| `commons-lang3` | 3.20.0 | spring-boot-dependencies |
| `jakarta.servlet-api` | 6.1.0 | spring-boot-dependencies |
| `jakarta.validation-api` | 3.1.1 | spring-boot-dependencies |
| `junit` / `junit-jupiter` (12 `junit-*` entries + `junit-bom` platform
import) | 6.0.3 | Spring Boot already imports `junit-bom:6.0.3` |
| `mongodb` (bson, driver-core, driver-sync, bson-record-codec) | 5.8.0 |
spring-boot-dependencies |
| `rxjava3` | 3.1.12 | spring-boot-dependencies |
Also removed the `jakarta.servlet` / `jakarta.validation` excludes from
`grails-bom/base/build.gradle` - they only existed to win a since-resolved
selenium-vs-Spring-Boot conflict, and both versions now match Spring Boot.
## Kept intentionally
- **`graphql-java` 25.0** - retained as a deliberate drift tripwire
(rationale comment added), because `graphql-java-extended-scalars` is **not**
managed by Spring Boot and must move in lockstep.
- **`groovy` 4.0.32** - intentional major divergence vs Spring Boot's 5.0.6
(Grails 8 baseline / Spock 2.4-groovy-4.0).
- **`selenium` 4.38.0** - left pinned. It is now *behind* Spring Boot's
4.43.0, so dropping it would be a version bump (Geb/functional impact), not a
pure inheritance. Worth a separate follow-up decision.
- **`spring-retry` 2.0.11** - Spring Boot 4 dropped management.
## Legacy CLI fix (required so this doesn't regress)
`grails-shell-cli` builds its own dependency management by parsing the
published `grails-bom` POM, and previously **skipped** third-party imports such
as `spring-boot-dependencies` (there was a test enforcing this). After this
cleanup those versions only exist behind the Spring Boot import, so
`GrailsDependencyVersions` now follows third-party imported BOMs too, with:
- **cycle/duplicate protection** (`spring-boot-dependencies` is imported by
both `grails-bom` and `grails-base-bom`),
- **first-writer-wins precedence** so Grails' own pinned versions (e.g.
Groovy 4.0.32) still win over Spring Boot's, and
- **per-POM `${...}` property resolution** (fixes a latent property-table
clobbering bug during recursion).
The spec test that asserted third-party BOMs are never resolved was
inverted; precedence, cycle-protection and nested-import coverage were added.
## Verification
- Regenerated the `grails-bom` and `grails-base-bom` POMs and diffed against
baseline: **only the removed constraints disappear**; the
`spring-boot-dependencies` import remains, so consumers still get the versions.
- Resolved compile/runtime/test classpaths of representative modules
(`grails-data-mongodb-core`, `grails-codecs-core`, `grails-async-rxjava3`,
`grails-converters`, `grails-web-core`): every removed dependency resolves to
Spring Boot's identical version.
- `./gradlew validateDependencyVersions` passes across **all** modules.
- `./gradlew :grails-shell-cli:test` passes (including the new
`GrailsDependencyVersionsSpec` coverage).
--
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]
