Gradle 6.8-rc-1 is now available for testing; see the release notes for more information.
I think we discovered two issues today. I’ve been in contact with Benjamin Muskalla on this in the gradle community slack channel but for completeness raising it here too:
- We configure a custom executable for our tests pointing to a custom provisioned jdk. This path looks like this:
C:\Users\rene_groschke\.gradle\caches\transforms-3\427746e150133a4386c5127f996642dd\transformed\windows-15.0.1-x64.zip\bin\java"This works as is in earlier gradle versions but is now failing with
A problem occurred starting process 'command 'C:\Users\rene_groschke\.gradle\caches\transforms-3\427746e150133a4386c5127f996642dd\transformed\windows-15.0.1-x64.zip/bin/java''
A build scan can be found here: https://scans.gradle.com/s/fc6g2zuxzuk5w/failure?expanded-stacktrace=WyIwIl0#1 The culprit seems to be a check if that file exists (see https://github.com/gradle/gradle/blob/02ef3ebd17982319865b4bb0eeaab72894660278/subprojects/jvm-services/src/main/java/org/gradle/internal/jvm/inspection/DefaultJvmVersionDetector.java#L43)
The java file exists under that explicit path but I noticed that the java file properties show that the “original file” is java.exe. (see attached screenshot)
IMO its quite counterintuitive that this doesn’t work (even though it worked before)
- The second is a minor issue: We noticed that InstallationLocation#getSource() of locations resolved from javaInstallationRegistry.listInstallations() do not list multiple sources for a certain jdk. E.g. If I configure environment variables like JAVA12_HOME to a sdk installed JDK, the source for that jdk is non deterministic and can be shown as “SDKMAN!” or “environment variable”. Ideally it would list both. For now we worked around that by disabling auto detection which skips SDKMAN! detection. Thanks Benjamin Muskalla for that hint.
cheers,
René