You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Execution failed for task ':micrometer-registry-azure-monitor:downloadDependencies'.
> Could not resolve all dependencies for configuration ':micrometer-registry-azure-monitor:testCompileClasspath'.
> Failed to calculate the value of task ':micrometer-test:compileJava11Java' property 'javaCompiler'.
> Unable to download toolchain matching the requirements ({languageVersion=11, vendor=any, implementation=vendor-specific}) from 'https://api.adoptium.net/v3/binary/latest/11/ga/linux/x64/jdk/hotspot/normal/eclipse'.
> Could not copy file '/home/********/.gradle/jdks/OpenJDK11U-jdk_x64_linux_hotspot_11/jdk-11.0.17+8/legal/jdk.crypto.ec/ecc.md' to '/home/********/.gradle/jdks/eclipse_adoptium-11-amd64-linux/jdk-11.0.17+8/legal/jdk.crypto.ec/ecc.md'.
> /home/********/.gradle/jdks/eclipse_adoptium-11-amd64-linux/jdk-11.0.17+8/legal/jdk.crypto.ec/ecc.md (Permission denied)
This started happening on the 1.10.x and main branches after upgrading to Gradle 7.6. Prior maintenance branches do not use the mrjars plugin, which is why I think they are unaffected. The version of mrjars did not change, however, so I suspect the default vendor the JDK is being downloaded from changed in Gradle 7.6. It's strange that downloading from adoptium would not work on CircleCI, though. It's also worth noting that we should not need to download a JDK on our CI build because we are always using the latest JDK available, which is capable of compiling 11-compatible source code for the multi-release jar. This happens because the mrjars plugin sets the compiler to languageVersion=11 for 11-compatible source sets.
I've confirmed that reverting the Gradle upgrade makes the CI build pass again.
The text was updated successfully, but these errors were encountered:
See, for example, https://app.circleci.com/pipelines/github/micrometer-metrics/micrometer/3636/workflows/30833aec-3bf4-40c6-9b7b-d2c77fe0f732/jobs/19392 (or Gradle Enterprise https://ge.micrometer.io/s/vxhaweu5wfjhm)
This started happening on the
1.10.x
andmain
branches after upgrading to Gradle 7.6. Prior maintenance branches do not use the mrjars plugin, which is why I think they are unaffected. The version of mrjars did not change, however, so I suspectthe default vendor the JDK is being downloaded from changed in Gradle 7.6. It's strange that downloading from adoptium would not work on CircleCI, though. It's also worth noting that we should not need to download a JDK on our CI build because we are always using the latest JDK available, which is capable of compiling 11-compatible source code for the multi-release jar. This happens because the mrjars plugin sets the compiler tolanguageVersion=11
for 11-compatible source sets.I've confirmed that reverting the Gradle upgrade makes the CI build pass again.
The text was updated successfully, but these errors were encountered: