The GitHub Actions job "SiteMesh 2 Compatibility" on grails-core.git/feat/neo4j-gorm-registry-migration has failed. Run started by GitHub user borinquenkid (triggered by borinquenkid).
Head commit for run: 6f5975bf51f80292f383b6d17c2ad5eb0aee3423 / Walter Duque de Estrada <[email protected]> refactor(grails-data-neo4j): dedupe test/Jetty/driver build config, drop redundant BOM force Addresses jdaugherty's PR #15972 review feedback on grails-data-neo4j/boot-plugin/build.gradle: - Extracted the identical test{}/Jetty-force block (byte-for-byte duplicated across core, boot-plugin, and grails-plugin) into a shared grails-data-neo4j/gradle/neo4j-harness-test-config.gradle, applied via 'apply from:' - matching the existing gradle/*.gradle reusable-config convention used elsewhere in the repo, instead of leaving it inline per module. - Removed the local `configurations.all { resolutionStrategy { force "...neo4j-java-driver..." } }` block from all three modules. Verified empirically (dependencyInsight with the force temporarily disabled) that neo4j-java-driver still resolves to 4.4.13 "By constraint" once the force is removed - grails-bom's 'strictly' constraint (dependencies.gradle) already wins over Spring Boot BOM's newer, binary-incompatible driver version on its own. core/build.gradle keeps its own test{} block (systemProperty, maxParallelForks, forkEvery, -Xmx1028M) since those aren't shared with the other two modules; the shared file's jvmArgs now uses += so it appends the add-opens flags without clobbering core's own -Xmx setting regardless of apply order. grails-data-neo4j-core, grails-data-neo4j-spring-boot, and grails-data-neo4j full suites pass with no regressions (grails-data-neo4j-core's one failure, OptimisticLockingSpec, is confirmed pre-existing on the unmodified branch tip). codeStyle clean on all three modules. Co-Authored-By: Claude Sonnet 5 <[email protected]> Report URL: https://github.com/apache/grails-core/actions/runs/29180768682 With regards, GitHub Actions via GitBox
