-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parent project classloader scopes should be locked before evaluating any children project #4823
Comments
Is this relationship something that would be specified in the |
Gradle class loader scope hierarchy follows the project hierarchy. Note that configure-on-demand (COD) or not, the root project is always configured first.
If you are looking for workarounds see gradle/kotlin-dsl-samples#607 (comment) |
The issue can be reproduced without COD with Groovy scripts as follows.
https://scans.gradle.com/s/h3p6l5js65fig If you rename |
What adds to the difficulty to track that kind of issues with Groovy scripts is that if, in the reproducer above, Another manifestation can be observed by replacing the content of
Then you get a different error for the same issue: Again, if you rename |
Any updates? I just encountered this, kinda unpleasant. |
We are running into this in one of our builds that is mixed Groovy/Kotlin build scripts but use neither COD nor |
I can't share the full project but I do see it happen where we have something like this:
allprojects {
// some configuration of plugins.withId, tasks, other stuff
}
tasks {
val copyBunchOfStuff by creating(Copy::class) {
from(tasks.findByPath(":code:in:sub:assembleTar")) {
rename { "renamed-assembly.tar.gz" }
}
}
} Getting rid of the |
@mkobit I can't reproduce with your snippet, any chance you could narrow it down to a reproducer? Just a gut feeling, but does |
Possibly related to gradle/gradle#4823 as it only appeared after using evaluationDependsOn (via The Preprocessor and on jGui).
This issue is several years old now. We have a somewhat consistent repro, can we help report anything? |
We made a workground, hope it will work also for some of you. We have many projects, some of them use kotlin script, we have problem when run task of kotlin project with CoD(it can be easily reproduced by deleting the gradle cache and stopping the deamon), the root project is using groovy, so we add the following code to the build script of the root project, the idea is, for each kotlin project, evaluate its parent projects first.
|
Thanks @andy-maca for your solution. We've sporadically run into this issue for our projects since switching over to Kotlin build scripts. We had been re-ordering dependencies to try to encourage Gradle to resolve the parent projects first, which worked in most cases but was inconsistent and painful. I implemented your changes today and it seems to have fixed things for us so far. subprojects {
// Address https://github.com/gradle/gradle/issues/4823: Force parent project evaluation before sub-project evaluation for Kotlin build scripts
if (gradle.startParameter.isConfigureOnDemand
&& buildscript.sourceFile?.extension?.toLowerCase() == "kts"
&& parent != rootProject) {
generateSequence(parent) { project -> project.parent.takeIf { it != rootProject } }
.forEach { evaluationDependsOn(it.path) }
}
} |
After moving the clearly-defined client to a new "clients" directory in this PR we started getting error in docker build. Root cause seems to be gradle/gradle#4823 that is not fixed yet. This change is a workaround that suitable for docker build in clouds where no gradle files being cached. Workaround for local development is build with disabled configureondemand option once. For all further build it could be enabled back. Signed-off-by: zhernovs <[email protected]>
After moving the clearly-defined client to a new "clients" directory in this PR we started getting error in docker build. Root cause seems to be gradle/gradle#4823 that is not fixed yet. This change is a workaround that suitable for docker build in clouds where no gradle files being cached. Workaround for local development is build with disabled configure-on-demand option once. For all further build it could be enabled back. Signed-off-by: zhernovs <[email protected]>
After moving the clearly-defined client to a new "clients" directory in this PR we started getting error in docker build. Root cause seems to be gradle/gradle#4823 that is not fixed yet. This change is a workaround that suitable for docker build in clouds where no gradle files being cached. Workaround for local development is build with disabled configure-on-demand option once. For all further build it could be enabled back. Fixes oss-review-toolkit#3306 Signed-off-by: zhernovs <[email protected]>
After moving the clearly-defined client to a new "clients" directory in this PR we started getting error in docker build. Root cause seems to be gradle/gradle#4823 that is not fixed yet. This change is a workaround that suitable for docker build in clouds where no gradle files being cached. Workaround for local development is build with disabled configure-on-demand option once. For all further build it could be enabled back. Fixes #3306 Signed-off-by: zhernovs <[email protected]>
There is not much change when running the whole app from the root. But there would be a difference when running unit tests of a leaf module. In that case, the whole repo will be configured first before running the tests. |
That was my understanding too, when working on feature modules you would only configure your direct modules required. In some cases that could be a large difference? |
This issue is about using @Tolriq, sorry you are getting into troubles with dependencies catalogs and thanks for the report. The fact that this happens without configure-on-demand enabled make it look like a bug in how dependencies catalogs accessors work. Could you please open a separate issue, ideally with a self contained reproducer? |
@Tolriq your issue is via CLI or syncing the IDE |
Disabling |
…o fix CI issues See [1] for the upstream issue and [2] for the workaround explanation. [1] gradle/gradle#4823 [2] gradle/kotlin-dsl-samples#607 (comment)
…a93e) === Disable Gradle (incubating) configuration-on-demand as a workaround to fix CI issues See [1] for the upstream issue and [2] for the workaround explanation. [1] gradle/gradle#4823 [2] gradle/kotlin-dsl-samples#607 (comment) === Co-authored-by: rm3l <[email protected]>
=== Disable Gradle (incubating) configuration-on-demand as a workaround to fix CI issues See [1] for the upstream issue and [2] for the workaround explanation. [1] gradle/gradle#4823 [2] gradle/kotlin-dsl-samples#607 (comment) === Co-authored-by: rm3l <[email protected]>
Solves intermittent testing failure due sub-sub-projects structure. [1] [1] gradle/gradle#4823
Solves intermittent testing failure due sub-sub-projects structure. [1] [1] gradle/gradle#4823
Solves intermittent testing failure due sub-sub-projects structure. [1] [1] gradle/gradle#4823
In my case, it was happening while creating & adding a new module to the Android project. Turns out, it was happening because Android Studio was adding these 2 lines to project level gradle file:
Once I removed these it worked. I already had many modules added to the project without any issues, so I looked for what was different for this new one and that's how I found the issue. Would suggest anyone with this issue to do the same. |
Another case i found today:
any exception thrown inside this custom settings script during IDE gradle sync leads to same:
running |
I believe I'm running into the same bug with Gradle 8.0.1 (interestingly only on Windows) when inputs /
Running
fails on Windows with a lot of unresolved referenced and
But when running the failed task Also, running with configure-on-demand disabled works:
Wrapping inputs in |
Here's a summary of complete reproducers shared in this issue and their outcome as of Today. As noted in the comment for the second one, they are about using Reproducers:
Results with links to build scans:
All the actionable reproducers from this issue are fixed since Gradle 7.4. There are other open issues with Configure On Demand, see https://github.com/gradle/gradle/issues?q=is%3Aopen+is%3Aissue+label%3Ain%3Aconfigure-on-demand If you come across this issue, please look for existing ones and add your 👍 there or create a new issue. Also note that most of the classloading issues were already fixed in 6.8 by |
…ogether with Configure-on-Demand * See #4823 (comment) ---- This PR also adds a regression test for the reproducer mentioned in the comment linked above. Co-authored-by: Paul Merlin <[email protected]>
I see the PR merged but I'm confused by how to use it. Could you please elaborate ? I'm on Gradle 8.5 and my faulty script looks like this:
|
When using
evaluationDependsOn(p)
or Configure-On-Demand, it can happen a project is evaluated before its parent.When this happens, parent classloader scopes aren't locked. This works in most cases with Groovy scripts because Gradle doesn't run with
-Dorg.gradle.classloaderscope.strict=true
. It currently fails with Kotlin scripts because the Kotlin DSL provider requires parent scopes to be locked in order to deterministically compute script compilation classpaths.Groovy or Kotlin, letting the classpath vary depending on the order the projects are evaluated lead to hard to debug errors particularly when combined with configure-on-demand:
As suggested by @adammurdoch, this should be fixed by introducing some sort of implicit script classpath evaluation dependency between a child project and its parent.
See gradle/kotlin-dsl-samples#782 for some context
The text was updated successfully, but these errors were encountered: