The GitHub Actions job "CI - Groovy Joint Validation Build" on grails-core.git/refactor/grails-bom-decouple-build-deps has failed. Run started by GitHub user jamesfredley (triggered by jamesfredley).
Head commit for run: 20913cbbf74d938ec63f703f102cd8744645eeb4 / James Fredley <[email protected]> Stop leaking build-only dependencies into the application Grails BOM Problem ======= The Apache Groovy joint validation build has been catching transitive dependency version drift between Grails BOM constraints and the resolved runtime classpath. Most recently: Dependency version validation failed for project 'grails-async-gpars'. The following dependencies resolved to versions different from the BOM (:grails-bom): com.github.javaparser:javaparser-core - resolved 3.28.1, expected 3.28.0 A transitive dependency is upgrading these versions. Root cause: the application-facing BOMs (grails-bom, grails-base-bom, grails-hibernate5-bom, grails-micronaut-bom) were iterating gradleBomDependencies into their constraints, which leaked Grails-build-only artefacts (Gradle plugins, the JavaParser library used by the build's GroovydocEnhancer) into the published consumer BOM. When Apache Groovy internally bumped one of these (e.g. GROOVY-11989 javaparser-core 3.28.0 -> 3.28.1 on GROOVY_5_0_X HEAD), the resolved transitive version no longer matched the Grails BOM's constraint, breaking :validateDependencyVersions across most modules. The Grails-internal Gradle plugins, AST tooling, and asciidoctor-gradle plugin are not used by user-facing Grails artefacts and have no business appearing as managed-version constraints in the consumer BOM. They are already managed by grails-gradle-bom, which is exactly the BOM intended for Grails build classpath consumers. Fix === Introduce a gradleBomBuildOnlyDependencyKeys set in dependencies.gradle listing the artefacts that exist solely for the Grails build's own classpath. The four application-facing BOM projects skip these keys when iterating gradleBomDependencies into their constraints. grails-gradle-bom (the build-time platform) is unchanged and continues to manage them. Initial set (all five are unambiguous build-only artefacts): * asciidoctor-gradle-jvm (Gradle plugin) * asset-pipeline-gradle (Gradle plugin) * grails-publish-plugin (Gradle plugin) * javaparser-core (used by GroovydocEnhancerExtension; comes via groovy-groovysh transitively for end users) * spring-boot-gradle (Gradle plugin) Other gradleBomDependencies entries (jansi, jline, jline2, byte-buddy, commons-text, directory-watcher, jna, ant, ant-junit, asciidoctorj, objenesis, spring-boot-cli, spring-boot-loader-tools, jquery) remain in the application BOM because they are or may be used at runtime by Grails applications. Verification ============ ./gradlew validateDependencyVersions -> 184 actionable tasks, BUILD SUCCESSFUL against javaparser-core.version = 3.28.0 (the value that previously failed on 8.0.x because Groovy 5.0.6-SNAPSHOT pulled in 3.28.1 transitively). After the fix the application BOM no longer publishes a javaparser-core constraint at all, so transitive resolution is free to pick whichever version Apache Groovy was built against. Verified that the published BOMs no longer list build-only artefacts: base/default/hibernate5/micronaut POMs ABSENT: javaparser-core, asciidoctor-gradle-jvm, asset-pipeline-gradle, grails-publish, spring-boot-gradle-plugin base/default/hibernate5/micronaut POMs PRESENT: jansi, jline, byte-buddy, commons-text, directory-watcher, ant-junit (legitimate runtime/test deps) Verified grails-gradle-bom still manages the build-only artefacts so Grails-internal Gradle plugin development is unaffected. Backwards compatibility ======================= End-user impact: any Grails application that was relying on grails-bom to manage javaparser-core, asciidoctor-gradle-jvm, asset-pipeline-gradle, grails-publish-plugin, or spring-boot-gradle-plugin will need to either pin the version directly or import grails-gradle-bom. We surveyed grails-core itself and only grails-data-graphql/plugin/build.gradle directly references javaparser-core (line 38: pinned at 3.25.7 explicitly, doesn't use the BOM-managed version), so this is unlikely to affect downstream consumers in practice. Gradle plugins are normally applied via the plugins {} block with a literal version anyway, not via BOM resolution. Assisted-by: claude-code:claude-opus-4-7 Report URL: https://github.com/apache/grails-core/actions/runs/25586612911 With regards, GitHub Actions via GitBox
