jdaugherty commented on PR #16325:
URL: https://github.com/apache/grails-core/pull/16325#issuecomment-5593633558
Thanks @matrei I see now why it can't reoccur. From discussing with AI, I
thought it would be helpful to paste it's output here. It seems the only
regression is if a configuration script was being provided manually (see the
end of the AI output). @codeconsole or @matrei would you mind addressing this
with an entry in the upgrade guide?
# PR #16325 / compileGroovy config-generator regression check
**Bottom line:** the regression does not exist on 8.0.x, PR #16325's test
really does guard it, and asset-pipeline was not the trigger. One related shape
does still behave differently from the old `doFirst`, detailed at the end.
## What the old regression actually was
The pre-September-2025 wiring registered per-script tasks that declared
`inputs.files(configurations.runtimeClasspath)`, with `compileGroovy` depending
on them. PR #15076 names the mechanism: "any task that interacts with the
runtime classpath now needs to declare a dependency on our customization task".
Two concrete failures follow from that input:
- Any task whose output lands on the runtime classpath and itself depends on
`classes` closes a cycle through the config task.
- The config task forces `runtimeClasspath` resolution just to write a
script, so a build that cannot resolve at that point fails on the generator
rather than the compile.
## Why it cannot recur with the merged design
The generator from #16114 takes a string input and, optionally, the build's
own config script file. It declares no classpath input, and its only task
dependency is the producer of that user script.
Confirmed on real builds: in `grails-test-examples-app1` (asset-pipeline,
GSP, three plugin subprojects), dry runs of `bootJar`, `compileGroovyPages`,
`integrationTestClasses` and `bootRun` all build their graphs with the
generator scheduled directly before each project's `compileGroovy` and nothing
else attached.
## PR #16325 verification
- The spec passes on the PR branch, 11 of 11, including the new cycle test.
- **Mutation check:** re-adding
`t.inputs.files(project.configurations.named('runtimeClasspath'))` to the
generator and rerunning the spec makes the new test fail with exactly the old
cycle:
```
Circular dependency between the following tasks:
:classes
\--- :compileGroovy
\--- :generateCompileGroovyGrailsCompilerConfig
\--- :packageRuntimeExtra
\--- :classes (*)
```
Seven other tests also fail under the mutation because the generator then
needs to resolve `runtimeClasspath` (`Cannot resolve external dependency
org.apache.grails:grails-bom`), which is the second failure mode above. The
suite catches either form of the regression.
- The one red CI check is the known flaky Geb login test tracked in #16030,
on the Groovy snapshot canary job. Unrelated.
## Asset-pipeline was not the cause
From the 5.2.0-M3 sources, `assetCompile` reads the `runtimeClasspath` and
`compileClasspath` configurations and is depended on by `bootJar` (or
`processResources` when `developmentRuntime` is off). Nothing it produces
reaches `compileGroovy`.
A fixture with the real plugin plus `grails-web`: with the current wiring a
full `bootJar` succeeds, and even with the old wiring simulated on the
generator the graph still builds, because in a single project nothing
task-built is on `runtimeClasspath`. The cycle needs a task-built runtime
classpath entry that depends on `classes`, which is the shape the PR's fixture
uses and the shape custom packaging steps or the old exploded-plugin wiring
produced.
## The remaining gap
A Grails 7-style build that writes its own compiler config script in a task
and wires it the old way:
```groovy
tasks.named('compileGroovy') {
dependsOn generateUserConfigScript
groovyOptions.configurationScript = file('build/user-config.groovy')
}
```
fails on 8.0.x head (`e8d33a9318`) because the generator has no edge to that
producer:
```
A problem was found with the configuration of task
':generateCompileGroovyGrailsCompilerConfig'
Input file does not exist ... property 'configurationScript' specifies file
'.../build/user-config.groovy' which doesn't exist
```
Provider wiring works, and the combined script carries both the Grails and
user imports:
```groovy
groovyOptions.configurationScriptFile.fileProvider(generateUserConfigScript.map
{ it.outputs.files.singleFile })
```
The #16114 author acknowledged this in that thread and promised a follow-up
regression test plus upgrade-guide text. Neither is on 8.0.x yet: the upgrade
guide's section 53 covers only `importJavaTime`, and #16325 does not cover this
case. That follow-up should be the condition for calling this area closed.
Options:
1. Document the provider wiring as a required change in the upgrade guide.
2. Have the generator inherit `compileGroovy`'s explicit `dependsOn` edges
when the user script is a plain file, accepting the author's concern that this
could reintroduce cycles.
--
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]
