Configurable java toolchains #2193
Conversation
Generate changelog in
|
|
|
||
| javaVersions = project.getObjects().mapProperty(JavaLanguageVersion.class, String.class); | ||
| javaVersions.putAll(project.provider(() -> parseOutVersions(project, JAVA_VERSION_PATTERN))); | ||
| javaVersions.finalizeValueOnRead(); |
There was a problem hiding this comment.
Do you think we could define these at most once per repo instead of per-module? (possibly BaselineJavaVersionsExtension.java, which only exists on the root project)
I don't think we would want the values to differ across modules.
There was a problem hiding this comment.
Heh actually in the process of doing this right now. The BaselineJavaVersion vs BaselineJavaVersions difference was lost on me for a little bit.
There was a problem hiding this comment.
I could have named things much better 😞 Sorry!
|
|
||
| private Path findJavaHome(Path temporaryJdkPath) { | ||
| try (Stream<Path> files = Files.walk(temporaryJdkPath)) { | ||
| return files.filter(file -> Files.isDirectory(file) && file.endsWith(Paths.get("Contents/Home"))) |
There was a problem hiding this comment.
I think only the mac jdks use this directory structure. We may want to find bin/java and walk back a directory
There was a problem hiding this comment.
Mmmm, I actually only had to do this because the commons-compress or jarchivelib don't support symlinks, maybe with an artifact transform I wouldn't need to do this
| } | ||
|
|
||
| try { | ||
| Files.move(findJavaHome(temporaryJdkPath), jdkPath, StandardCopyOption.ATOMIC_MOVE); |
There was a problem hiding this comment.
atomic move is great, however in some cases it's not possible (depending on the filesystem, or the src and destination are on different physical disks). Unsure if that will be an issue here.
There was a problem hiding this comment.
Filesystems are scary
| Path jdkArchive = azulJdkDownloader.downloadJdkFor(jdkSpec); | ||
|
|
||
| Archiver archiver = ArchiverFactory.createArchiver(jdkArchive.toFile()); | ||
| Path temporaryJdkPath = Paths.get( | ||
| jdkPath + ".in-progress-" + UUID.randomUUID().toString().substring(0, 8)); | ||
| try { | ||
| try { | ||
| archiver.extract(jdkArchive.toFile(), temporaryJdkPath.toFile()); | ||
| } catch (IOException e) { | ||
| throw new RuntimeException("Failed to extract jdk to directory", e); | ||
| } |
There was a problem hiding this comment.
I wonder if it would be possible/beneficial to leverage gradle cacheable artifact transforms?
That way we could reuse the same unpacked jdk across projects/checkouts instead of extracting in each repo.
There was a problem hiding this comment.
I was actually just going to extract to ~/.gradle/gradle-baseline/jdks to reuse jdks across repos and depend on the using a hash to keep them the same - but this is worth investigating, particularly as I wouldn't have to write all this caching code myself!
…llumr/custom-toolchains
###### _excavator_ is a bot for automating changes across repositories. Changes produced by the roomba/latest-baseline-oss check. # Release Notes ## 4.118.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Results of boolean logic are considered safe | palantir/gradle-baseline#2232 | ## 4.119.0 | Type | Description | Link | | ---- | ----------- | ---- | | Feature | Add a configuration point for providing your own JDKs to all java requiring tasks. | palantir/gradle-baseline#2193 | ## 4.120.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Fix intellij gradle integration copyright configuration | palantir/gradle-baseline#2234 | To enable or disable this check, please contact the maintainers of Excavator.
Before this PR
We use Gradle's in built java toolchain support . However, it has many downsides:
After this PR
Add a configuration point so plugins can supply their own JDKs per java major version:
Another plugin I am yet to write will download JDKs based on some configuration from various different sources eg Azul Zulu, Amazon Corretto etc
Possible downsides?