fix: defer compile-classpath probes out of GroovyCompile task configuration - #16076
Merged
jdaugherty merged 1 commit intoAug 1, 2026
Merged
Conversation
…ration
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.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 8.0.x #16076 +/- ##
================================================
+ Coverage 0 51.8562% +51.8562%
- Complexity 0 18110 +18110
================================================
Files 0 2046 +2046
Lines 0 96274 +96274
Branches 0 16727 +16727
================================================
+ Hits 0 49924 +49924
- Misses 0 38980 +38980
- Partials 0 7370 +7370
🚀 New features to boost your workflow:
|
✅ All tests passed ✅🏷️ Commit: 4fdb88b Learn more about TestLens at testlens.app. |
sbglasius
approved these changes
Aug 1, 2026
jdaugherty
approved these changes
Aug 1, 2026
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On Gradle 9.5+, running a task that depends on
compileClasspathwithout also depending on the compile task — e.g. asset-pipeline'sassetCompile— fails during task-graph construction:The chain (observed from a Grails 8.0.0-M4 app on Gradle 9.6.1):
assetCompileresolvescompileClasspathfor build dependencies.compileGroovytask.GrailsGradlePlugin.configureGroovyCompiler'sconfigureEachcallback, which callsgetGroovyCompilerScript→isClassOnClasspath(compile.classpath, …)→classpath.files— re-entering the resolution already in flight.markAsObservedIllegalStateException. Older Gradle (9.4.x and below) tolerated it silently.Invocations that realize the compile tasks during task selection (
build,compileGroovy, or evenassetCompile compileGroovy) are unaffected, which makes the failure look sporadic.Fix
Move the star-import computation — including the two
isClassOnClasspathclasspath probes — inside the closure thatgetGroovyCompilerScriptreturns. That closure is only invoked from the task'sdoFirst, at execution time, where resolving the classpath is legal. Nothing at task-configuration time touches the classpath anymore.The
GrailsPluginGradlePluginoverride already invokes the parent closure lazily inside its own closure (parent?.call() ?: ''), so it composes unchanged, and the call site's existing null handling covers the no-imports case.Verification
:grails-gradle-plugins:compileGroovypasses../gradlew assetCompilenow constructs its task graph and runs (previously failed as above), and the generatedgrailsGroovyCompilerConfig-compileGroovy.groovystill contains all three star-import packages (jakarta.validation.constraints,grails.gorm.annotation,grails.plugin.scaffolding.annotation), confirming the deferred probes see the same classpath. Full app compile succeeds with the auto-imports in effect.