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
We recently discovered the exciting new incubating feature related to configuring the Gradle Daemon JVM.
While we're keen on using the built-in toolchain provisioning support in Gradle, we found that some capabilities were missing when it was originally released. To address these gaps, we developed our own Gradle plugin called gradle-jdks that offers the following:
You can choose your favoured JDK vendor.
Use the same JDK version for representative, reproducible builds and tests on dev machines and in CI and in prod.
Automatically add JDK CA certificates to handle our corporate MITM proxy.
Point to an internal mirror for JDKs.
[WIP] Setting up the Gradle Daemon JDK out-of-the-box.
While the points 1 & 4 could now resolved using the toolchain plugins, we still have the following requirements that cannot be solved out-of-the-box by Gradle only:
Once Gradle finds an appropriate JDK on disk for that Java language version, it is always used and never updated.
As a company with tens of millions of lines of Java, we often bump into JVM bugs. It's highly desirable we test and deploy using the exact same version of JDKs.
Similarly, it's important to us that the exact same JDK versions are used on local machines as well as CI.
Gradle does not handle JDK CA certificates.
Many companies use TLS interception when network calls are made outside their corporate network. Gradle provides no way to install the relevant CA certificates into auto-provisioned JDKs. This means they cannot be used in such an environment, or require manual patching.
Gradle Daemon JVM setup does not take into consideration the toolchain gradle properties.
Upon initial testing, it appears that the daemon JVM setup might not be considering the auto-detect flag. Am I correct in this observation? From my analysis, even with the flags org.gradle.java.installations.auto-detect=false, org.gradle.java.installations.auto-download=false, and org.gradle.java.installations.paths=<custom_paths> set, the daemon JVM may still choose a JDK installation not present in the installations.paths. Is this the intended behavior ?
We would love to just use built in Gradle JDK support instead. Could we help out or be involved in providing feedback for this feature? I believe these requirements that we have and we implemented in gradle-jdks would greatly benefit other Gradle users.
The text was updated successfully, but these errors were encountered:
This feature request is in the backlog of the relevant team and is prioritized by them.
Note that daemon toolchain is a preview feature in upcoming Gradle 8.8 that still has rough edges.
For the second request, I am not sure we would want Gradle to mess up with JDK CA certificates. I think in that case, we would prefer that you use a custom provisioning plugin where the JDKs have the right setup.
The first item is a valid request and something we have heard from other users.
We recently discovered the exciting new incubating feature related to configuring the Gradle Daemon JVM.
While we're keen on using the built-in toolchain provisioning support in Gradle, we found that some capabilities were missing when it was originally released. To address these gaps, we developed our own Gradle plugin called gradle-jdks that offers the following:
While the points 1 & 4 could now resolved using the toolchain plugins, we still have the following requirements that cannot be solved out-of-the-box by Gradle only:
auto-detect
flag. Am I correct in this observation? From my analysis, even with the flags org.gradle.java.installations.auto-detect=false,org.gradle.java.installations.auto-download=false
, andorg.gradle.java.installations.paths=<custom_paths>
set, the daemon JVM may still choose a JDK installation not present in theinstallations.paths
. Is this the intended behavior ?We would love to just use built in Gradle JDK support instead. Could we help out or be involved in providing feedback for this feature? I believe these requirements that we have and we implemented in gradle-jdks would greatly benefit other Gradle users.
The text was updated successfully, but these errors were encountered: