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
Support for Gradle Configuration Cache #297
Comments
Thanks for the report but I can't reproduce the behaviour you have described using a minimal build.gradle:
I've tried with both 6.8.1 as you used and also with 6.8.3. In both cases, the output is the following:
Can you please provide some more detailed steps to reproduce the problem? Alternatively, could you attach to this issue a zip of the HTML report that Gradle generates? |
Thanks for looking into this! I checked the differences between your minimal build.gradle and my project and it looks like this starts to fail once you add the kotlin plugin to the game ( I did not expect that to make a difference... now I´m not sure if the behavior of the spring plugin changes once the kotlin plugin is there or if it not correctly claims that its io.spring.dependency-management fault 🙇♂️ |
Thanks. I've reproduced the problem now. The dependency management plugin reads the JVM's system properties to make them available to some embedded Maven code that resolves a dependency's effective pom. This is happening at execution time and my understanding is that the configuration cache only prohibits reading system properties at configuration time:
Here's a stacktrace for one of the problems:
The problem can be reproduced with Gradle 6.8.3 and the following
The script verifies that evaluation has completed before any configurations are resolved so I'm pretty sure that the system properties are being read at execution time. If that's correct then it looks like there's either a bug in Gradle or the documentation is understating the restrictions on reading system properties. I'll seek some guidance from the Gradle team. |
The undeclared system property reads are reported when calculating the task graph, after evaluation, before execution. Task graph calculation visits the dependencies of task inputs here Here's the configuration-cache-report.zip. The attribution of the problem could be better and explain the chain. Changing the script to report configurations resolved at task graph calculation time, before execution: // ... snip
def ready = false
gradle.taskGraph.whenReady {
println "Task Graph Ready"
ready = true
}
allprojects { project ->
configurations.all { configuration ->
configuration.incoming.beforeResolve {
println "Resolving $configuration"
if (!ready) {
throw new Exception("$configuration of $project is being resolved at configuration time")
}
}
}
} and running
I assume resolving that configuration triggers the spring dependency mangement plugin resolution rules. I think this property on the Kotlin compilation task should be a proper lazy In other words it looks like a problem in the Kotlin plugin to me. |
Thank you, @eskatos.
Yes, that's right. By default dependency management is configured "globally" (to all configurations) so resolution of
That tallies with the problem only occurring when the Kotlin plugin's applied. @Fabian-K can you please raise an issue with JetBrains and comment here with a link to it? |
I found gradle/gradle#13490 in general and https://youtrack.jetbrains.com/issue/KT-43605 specifically for kotlin |
KT-43605 is for a different problem when using Gradle's configuration cache so I'd recommend raising a new issue for your specific problem. As @eskatos said above, the problem you're seeing is due to the |
Sorry for the delay, I opened https://youtrack.jetbrains.com/issue/KT-45834 |
Thank you, @Fabian-K. |
Hi,
Gradle 6.8 has a new configuration cache feature that helps to improve build performance. Unfortunately, there are some restrictions on what plugins can use and the dependency-management-plugin is currently not compatible with this. It would be cool if it supports the configuration cache at some point :)
This should be reproducible with any sample project using gradle 6.8 and
gradlew --configuration-cache assemble
Thanks, Fabian
The text was updated successfully, but these errors were encountered: