codeconsole opened a new pull request, #16076:
URL: https://github.com/apache/grails-core/pull/16076
### Problem
On Gradle 9.5+, running a task that depends on `compileClasspath`
**without** also depending on the compile task — e.g. asset-pipeline's
`assetCompile` — fails during task-graph construction:
```
Could not determine the dependencies of task ':assetCompile'.
> Could not resolve all dependencies for configuration ':compileClasspath'.
> Could not create task ':compileGroovy'.
> Could not resolve all dependencies for configuration
':compileClasspath'.
> Cannot observe dependencies before markAsObserved(String) has
been called.
```
The chain (observed from a Grails 8.0.0-M4 app on Gradle 9.6.1):
1. Scheduling `assetCompile` resolves `compileClasspath` for build
dependencies.
2. Mid-resolve, Gradle freezes the configuration's attributes; the
target-JVM attribute's provider chain realizes the `compileGroovy` task.
3. Task realization fires `GrailsGradlePlugin.configureGroovyCompiler`'s
`configureEach` callback, which calls `getGroovyCompilerScript` →
`isClassOnClasspath(compile.classpath, …)` → `classpath.files` — re-entering
the resolution already in flight.
4. Gradle 9.5+'s stricter resolution state machine rejects the re-entrancy
with the `markAsObserved` `IllegalStateException`. Older Gradle (9.4.x and
below) tolerated it silently.
Invocations that realize the compile tasks during task selection (`build`,
`compileGroovy`, or even `assetCompile compileGroovy`) are unaffected, which
makes the failure look sporadic.
### Fix
Move the star-import computation — including the two `isClassOnClasspath`
classpath probes — inside the closure that `getGroovyCompilerScript` returns.
That closure is only invoked from the task's `doFirst`, at execution time,
where resolving the classpath is legal. Nothing at task-configuration time
touches the classpath anymore.
The `GrailsPluginGradlePlugin` override 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:compileGroovy` passes.
- Published the patched plugin locally and pointed the affected Grails
8.0.0-M4 app at it: `./gradlew assetCompile` now constructs its task graph and
runs (previously failed as above), and the generated
`grailsGroovyCompilerConfig-compileGroovy.groovy` still 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.
--
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]
