Gradle 7.0 configuration cache issues #179
Comments
|
Thanks. This was on my plan already, I will work on it an release 3.2 with jdk 16 support. |
|
With Gradle 7.4 the whole thing is no longer needed. Reading system properties is automatically configured correctly with the configuration cache: https://docs.gradle.org/7.4/release-notes.html#config-cache
Accessing the task's project is another issue, not sure if it easy to fix. |
|
The project access should be easy fixable: https://github.com/policeman-tools/forbidden-apis/blob/branch_3.1/src/main/resources/de/thetaphi/forbiddenapis/gradle/plugin-init.groovy#L49-L50 It looks like the |
|
According to https://twitter.com/thetaph1/status/1498631483887689732?s=20&t=cr1P9cI1pKgnrouTlY5PUg I will close this as "won't fix". |
|
Hi, although I marked this as won't fix I added a workaround which might fix the problem. I can't test this and so it may help or may not help: a70cb0e |
|
Hi, |
|
@uschindler Thanks for tackling this despite your reservations about Gradle! ❤️ |
|
I just closed it again to allow me to see that it was fixed. |
|
@uschindler , I'm afraid configuration cache is not supported in the current Here's an example: gradlex-org/build-parameters#95 (comment) The log you mention #179 (comment) doesn't really use configuration cache: Unfortunately, Would you please reconsider? |
|
I tested this several times back at that time. The problem here looks like the configuration cache can't correctly handle the closures used in the ConventionMapping. This code was changed since my tests. |
They do some transformation to support lambdas.
I guess it is tangential to the current issue. The tasks like |
|
First of all, I can confirm the issue with recent codebase. After the "third" axecution it fails with exactly the same issue.
Not really, changing this to a statically compiled version would be a big change in the build system (currently using ANT). I tried to convert the plugin to use Gradle as build system instead of ant, but at end it failed due to classpath pollution by old ASM versions (as soon as you add When refactoring the whole plugin into "subprojects" (one with the core logic and Apache Ant support as CLI and two separate ones for Maven and Gradle), I could manage to make the build working with Gradle. With the current setup compiling the Gradle plugin is impossible (as the artifacts to compile against are not on Maven Central or any Maven repo), so not reachable to any Maven or Ant build, you need a local gradle installation to to compile. |
|
I reopened the issue and set a milestone for 4.0, but as said befor ethis is a major - and backwards incompatible change - so is not a "simple bugfix". |
|
Here is my quick test, it fails when you execute it two times after each other: |
|
Anyways, as stated before: This configuration cache is a total desaster. It does not work in any project I am working with. It is a huge hack and against all good concepts of programming. The hacks (like this one triggers) are not worth to support it. So basically, a rewrite may change the issue, but as stated before: This plugin does not support configuration cache "officially" and will never do. |
|
FWIW starting with Gradle 8.0 configuration cache problems should surface on the first run. |
You can use https://central.sonatype.com/artifact/dev.gradleplugins/gradle-api/8.0.2/versions dependency (or whatever version you prefer) See https://docs.nokee.dev/manual/gradle-plugin-development.html#sec:gradle-dev-redistributed-gradle-api |
Hi, This may have changed in the meanttime. I will try to rewrite the code with Java and keep the Groovy code to a minimum or remove it completely. I just need so time to try out. The downside is that code gets verbose (like 5 times as much code as it cannot be written so elegant). If I can make it work with pure Java and only using the dependencies that are availabe on the Gradle Repository (or Maven central). Uwe P.S.: dev.gradleplugins Maven coordinates are there for not so long time. They redeployed all of those recently. That's good because I can remove the legacy repository that is currently added to the forbiddenapis build. Thanks for the pointer. This was a long-ongoing issue of complaints that the Gradle APIs and core parts of its implementation were not available on Maven Central and only in some undocumented/unmaintained repos. |
|
Hi, I will look into rewriting the Groovy code to be statically linked (some if/else statements are there to support older/newer versions). |
|
I have full-java version almost ready :-) The following is still missing:
|
|
Rewriting the So I created a simple PR that just restructures the code and compiles the groovy code as a full class This is also the solution with minimal risk, as the code is basically the same, just compiled at build time. It also has "indy" (invokedynamic) features enabled. JAR file looks like this, so Groovy classes are included: |
|
I also checked the configuration cache with running it three times: works. I will merge the PR now. New version will be released when Java 20 came out and ASM was updated for Java 21. |
|
I also verified that it works with Gradle 8.0.2 on Jenkins (but I didn't check the configuration cache). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using the Forbidden API Checker (version 3.1) with Gradle 7.0 and the configuration cache, the following issues are being logged:
See also: gradle/gradle#13490
The text was updated successfully, but these errors were encountered: