Remove the hardcoded servlet API dependency from gspCompile

[codeconsole]

What

GroovyPagePlugin declared jakarta.servlet:jakarta.servlet-api:6.0.0 on the gspCompile configuration it registers. This PR removes the dependency entirely. The gspCompile configuration is kept as an extension point for additional GSP-compile-only dependencies; empty, it resolves trivially.

Why it's redundant

The servlet API already reaches the compile classpath transitively wherever GSPs can compile at all:

• grails-web-gsp exposes grails-web-taglib via api
• grails-web-taglib exposes jakarta.servlet:jakarta.servlet-api via compileOnlyApi (needed for the TagLibrary trait)
• (grails-console contributes a second route via a plain api dependency in apps)

Since compiling a GSP definitionally requires the grails-gsp artifacts on the classpath, the servlet API always tags along — BOM-versioned (spring-boot-dependencies → 6.1.0 today), with jakarta-servlet.version property overrides working via BomPropertyOverridesPlugin.

Empirical verification

A bare Grails plugin project — groovy + grails-plugin + grails-gsp plugins, implementation 'org.apache.grails:grails-gsp' + grails-web-boot, one GSP exercising params/request/session and g:each/g:link/g:form, no servlet-api declaration anywhere — compiles its GSPs successfully against published 8.0.0-M4 artifacts with this dependency deleted. dependencyInsight confirms jakarta.servlet-api:6.1.0 arrives on compileClasspath purely via the transitive routes above, and the gspCompile configuration resolves empty.

Why the hardcode was worth removing

• It had drifted: pinned 6.0.0 while the Spring Boot 4 BOM manages 6.1.0 — any hardcoded version here needs a manual bump on servlet-level changes, and nobody remembers.
• It registered an explicitly-versioned dependency that version-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.
• With no dependency at all, the grails { bom = null } and standalone-grails-gsp cases need nothing: there is no version to supply and nothing to resolve.

Verified with :grails-gradle-plugins:compileGroovy and :grails-gradle-plugins:test, plus the external probe project above.

[jdaugherty]

I'm ok to merge this if @matrei is. I think he had been making changes to not rely on transitive dependencies. GSP's project structure is odd to me though so maybe it's explicit due it's split. I want his approval to merge this.

[matrei]

@jdaugherty @codeconsole We can remove it, but we should also add it to grails-web-gsp as compileOnlyApi. Otherwise we are depending on grails-web-taglib to always be included, which it does not have to be.

We should also add a comment in the GroovyPagePlugin where we are registering the gspCompile configuration, that it is an extension point for applications to add compile dependencies for GSP compilation. I can't think of a use case for that right now, and if there is no use case, we could remove the gspCompile configuration all together.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.9586%. Comparing base (3d129b7) to head (ea59fc5).

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #16068        +/-   ##
==================================================
- Coverage     51.9800%   51.9586%   -0.0214%     
+ Complexity      18035      18027         -8     
==================================================
  Files            2038       2038                
  Lines           95708      95707         -1     
  Branches        16648      16648                
==================================================
- Hits            49749      49728        -21     
- Misses          38622      38643        +21     
+ Partials         7337       7336         -1     

Files with missing lines	Coverage Δ
...ls/gradle/plugin/views/gsp/GroovyPagePlugin.groovy	0.0000% <ø> (ø)

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[testlens-app]

✅ All tests passed ✅

🏷️ Commit: ea59fc5
▶️ Tests: 66022 executed
⚪️ Checks: 62/62 completed

---

Learn more about TestLens at testlens.app.