codeconsole opened a new pull request, #16068:
URL: https://github.com/apache/grails-core/pull/16068

   ## What
   
   `GroovyPagePlugin` declares `jakarta.servlet:jakarta.servlet-api:6.0.0` 
directly on the `gspCompile` configuration it registers. This PR drops the 
hardcoded version and lets the BOM govern it:
   
   ```groovy
   project.dependencies.add('gspCompile', 'jakarta.servlet:jakarta.servlet-api')
   project.dependencies.constraints.add('gspCompile', 
'jakarta.servlet:jakarta.servlet-api') {
       it.version { it.prefer('6.0.0') }
   }
   ```
   
   ## Why
   
   - `GrailsGradlePlugin.applyGrailsBom` already adds the selected grails-bom 
as a `platform()` to **every** declarable configuration — including 
`gspCompile` (it is not in `isExcludedFromBomPlatform`). The hardcoded version 
is therefore redundant in any normal build.
   - It has drifted: the Spring Boot 4 BOM imported by grails-bom manages 
servlet-api **6.1.0** (Tomcat 11 / Servlet 6.1), while this pin sat at 6.0.0. 
Left hardcoded, it needs a manual bump on every servlet-level change and nobody 
remembers (this one was missed).
   - With the version BOM-managed, `jakarta-servlet.version` property overrides 
now reach the GSP compile classpath too, via `BomPropertyOverridesPlugin` — 
consistent with every other configuration.
   - The hardcode also registers an explicitly-versioned dependency object that 
dependency-scanning tooling (e.g. the ben-manes versions plugin with 
declared-only filtering) reports as if the build had declared it, which is how 
this was noticed.
   
   ## Behavior matrix
   
   | Scenario | Before | After |
   |---|---|---|
   | Normal app/plugin (BOM applied) | direct `6.0.0` vs BOM constraint; 
conflict resolution decides | BOM version, cleanly |
   | `jakarta-servlet.version` override | not applied to gspCompile's own dep | 
applied |
   | `grails { bom = null }` | 6.0.0 | 6.0.0 (via `prefer` fallback) |
   | `org.apache.grails.gradle.grails-gsp` applied standalone | 6.0.0 | 6.0.0 
(via `prefer` fallback) |
   
   A `prefer` constraint is intentionally weak: it supplies a version only when 
nothing else does, and loses to any BOM/platform `require` — so no build that 
currently resolves via the BOM changes behavior.
   
   Verified with `:grails-gradle-plugins:compileGroovy` and 
`:grails-gradle-plugins:test`.


-- 
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]

Reply via email to