search

krakowski / gradle-jextract

Gradle plugin for integrating Project Panama's jextract tool
https://plugins.gradle.org/plugin/io.github.krakowski.jextract
GNU General Public License v3.0
51 stars 10 forks source link

Adapt Gradle's toolchain mechanism for selecting JDKs #2

Closed krakowski closed 3 years ago

krakowski commented 3 years ago

What should this feature provide?

A way to specify the toolchain to be used for compiling and executing using Gradle's standard mechanisms.

Why is this feature needed?

The current way of specifying the toolchain through a custom Gradle property (javaHome) is not an elegant solution and may break in future Gradle versions. This will also reduce the cost of maintenance.

How can this feature be implemented?

As explained in Toolchains for plugin authors, the custom task should expose a toolchain property, letting the user configure which toolchain to use.

elect86 commented 3 years ago

I've done already this in my fork, would you like a PR?

krakowski commented 3 years ago

This would be great! Will this work using (just) the following snippet inside the build script?

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(17))
    }
}
elect86 commented 3 years ago

Mostly yes.

However I added a new task to automatically download (and extract) the last Early Access build to buildDir

If the user doesn't have that jdk already, he can use this task (which will also set accordingly org.gradle.java.installations.paths in "gradle.properties`)

What do you think?

Ps: I'm also working on the CI pipeline to build and release automatically snapshots in my fork. I'd suggest we both focus our effort on this because it's official and we can build multiple platforms (I also have macos x64 working). I just dealing now with a single damn test failing, which invalidate the whole flow and how to use properly the github action to release.

krakowski commented 3 years ago

Hi,

I was working on this today and got it working using Gradle's toolchain mechanism. Gradle will now autodetect the installed JDK or look in other locations specified inside org.gradle.java.installations.paths. Please have a look at the updated jextract-demo repository.

However I added a new task to automatically download (and extract) the last Early Access build to buildDir

If the user doesn't have that jdk already, he can use this task (which will also set accordingly org.gradle.java.installations.paths in "gradle.properties`)

What do you think?

I would like to keep the gradle-jextract plugin simple in regard to its functionality. Ideally, it should just call the jextract tool. However, downloading additional JDKs could very well be implemented in a standalone plugin, as it could also be interesting for people who do not use jextract. Such a plugin could use your CI pipeline builds as a source.

Ps: I'm also working on the CI pipeline to build and release automatically snapshots in my fork. I'd suggest we both focus our effort on this because it's official and we can build multiple platforms (I also have macos x64 working). I just dealing now with a single damn test failing, which invalidate the whole flow and how to use properly the github action to release.

Sounds cool! Once this is set up I could use it for my SDKMAN! installation script.