The GitHub Actions job "CI - Groovy Joint Validation Build" on grails-core.git/fix/eager-classpath-resolve-8.0.x has succeeded. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: 4fdb88b163175ec569816aeedace3a021eac32bd / Scott Murphy Heiberg <[email protected]> fix: defer compile-classpath probes out of GroovyCompile task configuration getGroovyCompilerScript ran its isClassOnClasspath probes eagerly in the tasks.withType(GroovyCompile).configureEach callback, resolving the task's compile classpath at task-configuration time. A GroovyCompile task can be realized from inside an in-flight resolution of compileClasspath: scheduling any task whose inputs include that configuration (e.g. asset-pipeline's assetCompile) realizes the compile task through the target-JVM attribute's provider chain. The callback then re-enters the resolution already in flight, which Gradle 9.5+ rejects with IllegalStateException: Cannot observe dependencies before markAsObserved(String) has been called failing the build with 'Could not determine the dependencies of task :assetCompile'. Builds that realize the compile tasks during task selection (build, compileGroovy) were unaffected, which is why the failure only shows for tasks like assetCompile that depend on compileClasspath without depending on the compile task. Move the classpath probes (and the rest of the script generation) inside the returned closure, which is only invoked from the task's doFirst at execution time, where resolving the classpath is legal. The GrailsPluginGradlePlugin override already invokes the parent closure lazily inside its own closure, so it composes unchanged. Report URL: https://github.com/apache/grails-core/actions/runs/30655230016 With regards, GitHub Actions via GitBox
