-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[Gradle] Autoprovision jvm for gradle daemon #124071
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
Conversation
|
Pinging @elastic/es-delivery (Team:Delivery) |
| ) | ||
| ] | ||
| toolchainPlatforms.set(myPlatforms) | ||
| languageVersion = JavaLanguageVersion.of(21) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jozala brought up that those archived oracle jdks are not openjdk anymore and we might hit a license issue here. I wonder if we are okay here or if we should maybe use a different openjdk vendor. @mark-vieira do you have thoughts on this?. IMO since this is build vm only. the safest way might be using adoptium
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forget the exact license terms. We aren't "redistributing" so we're probably ok, but I guess it would be considered "commercial use". If there are any concerns I agree that just using Adoptium would be easiest. We're not picky here, since this is only used by build-time toolchains.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets go with the Adoptium jvm then for the gradle jvm
| @@ -0,0 +1,8 @@ | |||
| #This file is generated by updateDaemonJvm | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see. It doesn't actually do dynamic resolution. This is still way better than the status quo though of people running into random issues when using new JDKs. And this rarely will need to be updated.
40063da to
64b64b0
Compare
With Gradle 8.13 we can now auto provision the jdk used by the gradle daemon. Our configuration relies on jdk21. With this autoprovisioning enabled each gradle build will use adoptium jdk 21 for gradle jvm
With Gradle 8.13 we can now auto provision the jdk used by the gradle daemon. Our configuration relies on jdk21. With this autoprovisioning enabled each gradle build will use adoptium jdk 21 for gradle jvm
With Gradle 8.13 we can now auto provision the jdk used by the gradle daemon. Our configuration relies on jdk21. With this autoprovisioning enabled each gradle build will use adoptium jdk 21 for gradle jvm
With Gradle 8.13 we can now auto provision the jdk used by the gradle daemon. Our configuration relies on jdk21. With this autoprovisioning enabled each gradle build will use adoptium jdk 21 for gradle jvm
With Gradle 8.13 we can now auto provision the jdk used by the gradle daemon. Our configuration relies on jdk21. With this autoprovisioning enabled each gradle build will use adoptium jdk 21 for gradle jvm
With Gradle 8.13 we can now auto provision the jdk used by the gradle daemon. Our configuration relies on jdk21. With this autoprovisioning enabled each gradle build will use adoptium jdk 21 for gradle jvm
With Gradle 8.13 we can now auto provision the jdk used by the gradle daemon. Our configuration relies on jdk21. With this autoprovisioning enabled each gradle build will use adoptium jdk 21 for gradle jvm
No description provided.