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
Fix reproducability of builds against Java EA versions (#132847) (#132975)
* Introduce dedicated toolchain resolver for EA java versions
* Fix reproducability of builds against Java EA versions
This fixes a reproducability issue when using the gradle javaToolChain api.
There is no way to test toolchain candidates reliable against the build number in use.
This meant that ones you e.g. have resolved some version of java 25, gradle toolchain detection
does not detect the difference between certain builds (or even ea vs. released version)
Therefore we fallback to rely on our custom JDKDownloadPlugin for now here.
Syncing with the gradle team, they want to fix this somewhen in 9.x. We will revisit our solution
ones something is available. Ultimately we want to get rid of usages of the JDK download plugin.
* Minor cleanup and fixing non set distribution type in jdk
* Fix ea jdk selection not just based on major version
explicitly requires to add a ea postfix to the runtime sys property
* Fix test reproduce linies when using java ea version
* Apply review feedback
* Use runtime jdk when patching
* More cleanup
(cherry picked from commit 16fe7db)
# Conflicts:
# BUILDING.md
Copy file name to clipboardExpand all lines: BUILDING.md
+23-9Lines changed: 23 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -186,6 +186,25 @@ dependencies {
186
186
187
187
To test an unreleased development version of a third party dependency you have several options.
188
188
189
+
### How do I test against java early access (ea) versions?
190
+
191
+
Currently only openjdk EA builds by oracle are supported.
192
+
To test against an early access version java version you can pass the major
193
+
java version appended with `-ea` as a system property (e.g. -Druntime.java=26-ea) to the Gradle build:
194
+
195
+
```
196
+
./gradlew clean test -Druntime.java=26-ea
197
+
```
198
+
199
+
This will run the tests using the JDK 26 EA version and pick the latest available build of the matching JDK EA version we expose
200
+
in our custom jdk catalogue at `https://storage.googleapis.com/elasticsearch-jdk-archive/jdks/openjdk/latest.json`.
201
+
202
+
To run against a specific build number of the EA build you can pass a second system property (e.g. `-Druntime.java.build=6`):
203
+
204
+
```
205
+
./gradlew clean test -Druntime.java=26-ea -Druntime.java.build=6
206
+
```
207
+
189
208
#### How to use a Maven based third party dependency via `mavenlocal`?
190
209
191
210
1. Clone the third party repository locally
@@ -229,11 +248,8 @@ In addition to snapshot builds JitPack supports building Pull Requests. Simply u
229
248
3. Run the Gradle build as needed. Keep in mind the initial resolution might take a bit longer as this needs to be built
230
249
by JitPack in the background before we can resolve the adhoc built dependency.
231
250
232
-
---
233
-
234
-
**NOTE**
235
-
236
-
You should only use that approach locally or on a developer branch for production dependencies as we do
251
+
> [!Note]
252
+
> You should only use that approach locally or on a developer branch for production dependencies as we do
237
253
not want to ship unreleased libraries into our releases.
238
254
---
239
255
@@ -265,10 +281,8 @@ allprojects {
265
281
```
266
282
4. Run the Gradle build as needed with `--write-verification-metadata` to ensure the Gradle dependency verification does not fail on your custom dependency.
267
283
268
-
---
269
-
**NOTE**
270
-
271
-
As Gradle prefers to use modules whose descriptor has been created from real meta-data rather than being generated,
284
+
> [!Note]
285
+
> As Gradle prefers to use modules whose descriptor has been created from real meta-data rather than being generated,
272
286
flat directory repositories cannot be used to override artifacts with real meta-data from other repositories declared in the build.
273
287
For example, if Gradle finds only `jmxri-1.2.1.jar` in a flat directory repository, but `jmxri-1.2.1.pom` in another repository
274
288
that supports meta-data, it will use the second repository to provide the module.
Copy file name to clipboardExpand all lines: build-tools-internal/src/integTest/groovy/org/elasticsearch/gradle/fixtures/AbstractGitAwareGradleFuncTest.groovy
Copy file name to clipboardExpand all lines: build-tools-internal/src/integTest/groovy/org/elasticsearch/gradle/internal/JdkDownloadPluginFuncTest.groovy
+36-20Lines changed: 36 additions & 20 deletions
Original file line number
Diff line number
Diff line change
@@ -33,13 +33,18 @@ class JdkDownloadPluginFuncTest extends AbstractGradleFuncTest {
0 commit comments