jamesfredley commented on PR #15365:
URL: https://github.com/apache/grails-core/pull/15365#issuecomment-4261200308
## CI Fix Pushed (237527b)
Two root-cause fixes for the failing checks:
### 1. `Build Grails-Core` / `build_grails` - compile failure on
`:grails-test-examples-issue-11767:compileGroovy`
The previous attempt to resolve the duplicate
`META-INF/spring-configuration-metadata.json` in the `issue-11767` plugin
disabled `compileJava` outright. That broke the consumer app:
`grails-test-examples/issue-11767/AppController.groovy` imports
`issue11767.plugin.PluginJavaMicronautBean`, a real Java class, so
`compileGroovy` could no longer resolve the type.
**Root cause of the metadata duplicate:** both tools correctly emit
non-overlapping metadata for the beans visible to their own compiler:
- `micronaut-inject-java` (annotation processor, `compileJava`) writes
`build/classes/java/main/META-INF/spring-configuration-metadata.json`
describing `PluginJavaMicronautBean`.
- `micronaut-inject-groovy` (AST transform, `compileGroovy`, pulled in
transitively via `grails-micronaut`) writes
`build/classes/groovy/main/META-INF/spring-configuration-metadata.json`
describing `PluginGroovyMicronautBean`.
Both files are intentional for this fixture - it exists specifically to
exercise Java + Groovy beans sharing `@ConfigurationProperties('my')`.
`CompilePlugin` globally sets `jar.duplicatesStrategy = FAIL` to surface
accidental double-configuration, so the build (correctly) refuses to silently
pick one.
**Fix:** a new `mergeMicronautConfigMetadata` task merges the two JSON
documents (groups + properties + hints) into one file under
`build/classes/groovy/main/META-INF/` and deletes the Java-side copy, so the
jar task sees exactly one metadata file that describes both beans. No band-aid
(`DuplicatesStrategy.EXCLUDE` would drop one bean's metadata; disabling a
compile step would prevent consumers from using the class).
Verified locally:
```
./gradlew :grails-test-examples-plugins-issue-11767:jar
./gradlew :grails-test-examples-issue-11767:compileGroovy
```
Both succeed. `unzip -l` on the produced jar shows a single
`META-INF/spring-configuration-metadata.json` containing both
`PluginJavaMicronautBean` and `PluginGroovyMicronautBean` group entries and all
four `my.value1` / `my.value2` property entries.
### 2. `Validate Dependency Versions` - OpenTelemetry 1.55.0 vs 1.59.0
The PR bumped Selenium to `4.41.0`, which transitively requires
`io.opentelemetry:*:1.59.x`. Spring Boot `4.0.5`'s BOM still manages `1.55.x`,
so the shared dependency validator flagged every OpenTelemetry module in
`grails-test-examples-scaffolding` (which pulls Selenium via Geb integration
tests):
```
io.opentelemetry:opentelemetry-api - resolved 1.59.0, expected 1.55.0
io.opentelemetry:opentelemetry-context - resolved 1.59.0, expected 1.55.0
... (9 more)
```
`dependencyInsight` confirmed the version bump originates from
`org.seleniumhq.selenium:selenium-remote-driver:4.41.0`.
**Fix:** import `io.opentelemetry:opentelemetry-bom:1.59.0` from
`grails-bom` after `spring-boot-bom` so the grails-bom advertises the version
that is actually resolved. `./gradlew validateDependencyVersions` now succeeds
across every project.
### Files changed
- `dependencies.gradle` - add `opentelemetry.version` and
`opentelemetry-bom` platform import
- `grails-test-examples/plugins/issue-11767/build.gradle` - remove the
`compileJava` disable; add `mergeMicronautConfigMetadata` task with thorough
root-cause comments
--
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]
