The GitHub Actions job "Groovy Snapshot Canary Build" on grails-core.git/8.0.x has succeeded. Run started by GitHub user borinquenkid (triggered by borinquenkid).
Head commit for run: bb815fa39bb9f8edf71264b45bb696a0ade7dafe / James Fredley <[email protected]> Use SLF4J for runtime diagnostics (#15993) * Use SLF4J for runtime diagnostics Assisted-by: opencode:gpt-5.6-sol * Fix import order and isolate user.home in runner spec Assisted-by: opencode:gpt-5.6-sol * Document and de-duplicate the multi-SLF4J-provider test classpath Copilot flagged that grails-shell-cli's test classpath carries both slf4j-simple and logback-classic simultaneously, which SLF4J 2.x treats as an ambiguous binding. Verified this is real: `dependencies --configuration testRuntimeClasspath` resolves both providers together, and neither can simply be dropped - slf4j-simple is needed at runtime for the actual `grails` CLI executable's production logging, and logback-classic is needed by the new Logback-appender-based forked regression specs (SpringApplicationRunnerSpec, GrailsCliSpec). Confirmed no current regression from this (full :grails-shell-cli:test run is green, no "multiple SLF4J providers" warning appears in any test output) because both new specs that need a specific provider already pin it explicitly via -Dslf4j.provider=... in their forked child process. This commit removes the now-fully-redundant duplicate `testImplementation 'org.slf4j:slf4j-simple'` line (already pulled in via the runtimeOnly dependency, so this doesn't change the resolved classpath) and documents the coexistence so a future forked-process fixture doesn't skip the explicit pin and hit non-deterministic provider selection. Co-Authored-By: Claude Sonnet 5 <[email protected]> * Fix broken imports in SchemaExportCommandSpec after upstream CLI package move The 8.0.x branch relocated ApplicationCommand/ExecutionContext and each SchemaExportCommand into a dedicated cli source set with new packages (grails.dev.commands.ExecutionContext -> org.apache.grails.core.cli. ExecutionContext, grails.plugin.hibernate.commands.SchemaExportCommand -> org.apache.grails.data.hibernate{5,7}.cli.SchemaExportCommand) as part of unrelated work that landed after this PR's base commit. Merging origin/8.0.x picked this up cleanly via rename tracking for the production SchemaExportCommand.groovy files (already updated to the new package on merge), but the two new SchemaExportCommandSpec.groovy test files added by this PR had no prior history for git to track the rename through, so they were merged in unchanged - still importing the old ExecutionContext package and referencing SchemaExportCommand unqualified (previously fine only because the spec shared its production class's old package). Both left compileTestGroovy failing after the merge. Fixed by importing both classes from their new locations. Co-Authored-By: Claude Sonnet 5 <[email protected]> * test: record coverage for SLF4J diagnostics paths Codecov reported 13.88% patch coverage because the fixture specs verify the new logging behavior in forked JVMs that JaCoCo never instruments. Forward the test JVM's JaCoCo -javaagent argument into the forked processes so their execution data appends to the module exec file, and exercise the remaining ProfilingGrailsPluginManager configuration phases in-process with a probe plugin. Co-Authored-By: Claude Fable 5 <[email protected]> --------- Co-authored-by: Walter Duque de Estrada <[email protected]> Co-authored-by: Claude Sonnet 5 <[email protected]> Report URL: https://github.com/apache/grails-core/actions/runs/33217575479 With regards, GitHub Actions via GitBox
