jamesfredley commented on PR #15558: URL: https://github.com/apache/grails-core/pull/15558#issuecomment-4570773340
## Burn-down audit 2026-05-29 against Groovy 6.0.0-SNAPSHOT build #716 Pulled `grails8-groovy5-sb4` into the canary (merge `4a63acadb8`: Spring Boot 4.0.6, Gradle 9.5.1, Jackson 3 / mongodb 5.6.5 alignment; `dependencies.gradle` kept `groovy.version: 6.0.0-SNAPSHOT`) and re-audited every workaround against the latest published snapshot **6.0.0-20260527.104747-716** (master HEAD 2026-05-27, which now contains the GROOVY-12040 merge). ### Removed this cycle - **`ConfigurationBuilder` `@Builder`-detection heuristic** (commit `5d3896d0f2`). [GROOVY-12040](https://issues.apache.org/jira/browse/GROOVY-12040) ([apache/groovy#2565](https://github.com/apache/groovy/pull/2565), merged to `master` 2026-05-27) restores `@Builder` to `@Retention(RUNTIME)`. The `isLikelyBuilderType()` heuristic + its three call-site disjuncts were only needed because `Class.getAnnotation(Builder)` returned `null` under the SOURCE-retention regression; detection now reverts to the pre-Groovy-5 `getAnnotation(Builder)` form. The Spring 7 `Map`-to-typed-config conversion fallbacks (`handleConverterNotFoundException`, `handleConversionException`) are independent of the Groovy version and are retained. - **This fix is on `master` only - it is NOT yet backported to `GROOVY_5_0_X`.** So the Groovy 5 base PR #15557 still requires this workaround; the canary is the first branch that can drop it. - Verified: `:grails-datastore-core:test --tests ConfigurationBuilderSpec` (4/4 passed) + `:grails-datastore-core:codeStyle` green on build #716 / Gradle 9.5.1 / Spring Boot 4.0.6. ### Already cleared via the base merge - **`g.taglib` STC from `@CompileStatic` GSP** (former workaround #5) - resolved upstream-style by the [GROOVY-12041](https://issues.apache.org/jira/browse/GROOVY-12041) Grails-side change (`GroovyPageTypeCheckingExtension` matches the taglib namespace by name); now a real fix on the base, inherited here. The previous description's #5 row is dropped. ### Re-audited and KEPT (no upstream fix; fire identically on 5.0.7-SNAPSHOT and 6.0.0-SNAPSHOT #716) 1. `VariableScopeVisitor` canonicalization NPE guards (`GrailsASTUtils` / `AstUtils` / `AbstractMethodDecoratingTransformation`). 2. `gradle/boot4-disabled-integration-test-config.gradle` (indy=false controller-parameter scope loss + SiteMesh3/Spring 7). 3. `AbstractConstraint.getDefaultMessageFromBundle` interface static-init-order fallback (the surviving, non-`@Builder` half of the old ConfigurationBuilder row; defensive, needs a standalone reproducer). 4. `Validateable.resolveDefaultNullable()` reflection - [GROOVY-11985](https://issues.apache.org/jira/browse/GROOVY-11985) / [apache/groovy#2529](https://github.com/apache/groovy/pull/2529) still **OPEN**. ### Groovy-6-only blocker - still red - **`DefaultGrailsJsonViewHelper.groovy:67`** Verifier "abstract method in non-abstract class" regression: re-confirmed failing on build #716 (all 5 `render(...)` overloads). GROOVY-12040 does not touch the Verifier path. No upstream ticket yet; `grails-views-gson` remains the working reproducer and the canary's blocking CI category. ### Net The canary now carries **one fewer workaround than the Groovy 5 base** - the GROOVY-12040 `@Builder` fix is in `master`/6.0.0 (build #716) but not in `GROOVY_5_0_X`, so the canary drops a workaround that 5.0.x must keep. [apache/groovy#2529](https://github.com/apache/groovy/pull/2529) (the only other candidate) is still open; if it merges to `master` before `GROOVY_5_0_X`, the `Validateable` reflection shim becomes the next canary-only removal. The CI matrix on this push is the authoritative gate; the `grails-views-gson` Verifier blocker is expected to stay red until upstream. Assisted-by: claude-code:claude-4.8-opus -- 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]
