search

graalvm / native-build-tools

Native-image plugins for various build tools
https://graalvm.github.io/native-build-tools/
Other
367 stars 60 forks source link

Add an artifact that downloads GraalVM and Native Image #100

Open lazar-mitrovic opened 3 years ago

lazar-mitrovic commented 3 years ago

It can be a bit tricky for the end users to download and configure GraalVM. We can automate this process by providing an artifact that downloads and configures GraalVM and Native Image.

This artifact would be invoked by both Gradle and Maven plugins and would be configurable trough them (by specifying version, distribution, and/or even the URL) using extensions and configuration options.

Note that Windows support for this might be a bit harder (but certainly doable).

graemerocher commented 3 years ago

Gradle already supports the notion of tool chains which this should support imo

melix commented 3 years ago

I totally agree that we should provide a more build-tool friendly API to fetch a GraalVM build with native image preinstalled. Gradle's toolchain mechanism is two fold:

  1. it can identify JDK installations in "well-known" places: from $PATH, from OS specific paths (/usr/lib/..) or from common tools which are able to install JDKs by themselves (e.g SDKMan!).
  2. if no suitable JDK is found, it tries to download a compatible version from AdoptOpenJDKhttps://docs.gradle.org/current/userguide/toolchains.html#sec:provisioning

For both, there is a problem with GraalVM:

In 1., the problem is that even if you identify a GraalVM toolchain, there's no guarantee that the native-image tool would be installed. There should be a way to get a GraalVM SDK with the native image tool preinstalled.

For 2., the automatic provisioning is optional in Gradle. It uses the AdoptOpenJDK API to do this, but Gradle can be configured to use a different base URL for the download service. It means that GraalVM could provide an AdoptOpenJDK compatible API service to supply JDKs. It should be relatively easy to do so. Note that the API itself has nothing specific to Adopt. It can be used by any other vendor. However, again, what would be downloaded would have to come with native-image preinstalled to be build tool friendly.

melix commented 3 years ago

Related: https://github.com/gradle/gradle/pull/18028

sbrannen commented 3 years ago

Related: https://github.com/marketplace/actions/graalvm-native-image-toolchain

lazar-mitrovic commented 2 years ago

Related Gradle Roadmap entry: https://github.com/gradle/build-tool-roadmap/issues/29

sschuberth commented 2 years ago

It can be a bit tricky for the end users to download and configure GraalVM. We can automate this process by providing an artifact that downloads and configures GraalVM and Native Image.

Agreed. For Gradle, that's basically the only reason why we're using https://github.com/palantir/gradle-graal in https://github.com/oss-review-toolkit/ort rather than the Gradle plugin from this repo. I'm really hoping for https://github.com/gradle/gradle/pull/18028 to land soon (it's scheduled for Gradle 7.6 currently) to address the matter generically in Gradle itself.

frank-dspeed commented 2 years ago

what is the problem here i simply use

  1. download graalvm-ce and extract
  2. install native-image installs it or returns true if installed 
    $GRAALVM/bin/gu install native-image

so ensure installed is not a problem ??

cvmocanu commented 2 years ago

what is the problem here i simply use

  1. download graalvm-ce and extract
  2. install native-image installs it or returns true if installed
$GRAALVM/bin/gu install native-image

so ensure installed is not a problem ??

@frank-dspeed, let me re-phrase your question: "What is the point of Gradle toolchain auto provisioning?". And the answer is: convenience - you checkout a git project and it just works. No need to point people to a readme file with step-by-step instructions. It just works. That is also why we use the Gradle wrapper instead of asking everyone to install Gradle.

cvmocanu commented 2 years ago

BTW, the lack of auto-provisioning is why I'm also using the https://github.com/palantir/gradle-graal plugin instead of this one.

Slightly off topic: kudos to the GraalVM team (and the team behind this plugin)! It's very nice to be able to build a statically linked native Java executable.

frank-dspeed commented 2 years ago

@cvmocanu do i understand you correct your using nativ image gradle and graal with stock JDK?

cvmocanu commented 2 years ago

@frank-dspeed: I'm using the https://github.com/palantir/gradle-graal Gradle plugin. The plugin adds a nativeImage task which compiles to native binaries. I assume the Java source->bytecode compilation is done with a stock JDK, but I'm not sure if the plugin changes the Java compiler configuration or not.

As others said, that plugin does auto-provisioning (it downloads the specified version of GraalVM community to ~/.gradle/caches/com.palantir.graal/<version>, if it's not already downloaded locally). This is really convenient.

cvmocanu commented 2 years ago

I would love to use the official plugin (this one) though, instead of the palantir one.

sschuberth commented 2 years ago

Just wondering, could the work on this topic for the Gradle plugin already start now that Gradle 7.6 RC1 added support for Java Toolchain downloads from arbitrary repositories, despite https://github.com/gradle/gradle/pull/18028 not being merged yet?

frank-dspeed commented 2 years ago

i guess this gets solved as most of the graalvm parts get moved now to stock openjdk

sschuberth commented 1 year ago

i guess this gets solved as most of the graalvm parts get moved now to stock openjdk

I'm not sure whether it's worth waiting for that to happen in a new JDK release. Releasing a new plugin version that's able to bootstrap GraalVM with native image support now seems to be the much lower hanging fruit.

frank-dspeed commented 1 year ago

@sschuberth that was exactly what i did want to say 👍🏻 simply create a bash script and call it a day much faster written then java or use kotlin and not bash.

sschuberth commented 1 year ago

simply create a bash script and call it a day much faster written then java or use kotlin and not bash.

That, however, is not what I wanted to say 😉 : Adding a few lines of Kotlin / Java code to implement a toolchain resolver plugin is quicker than waiting for a new JDK release, and much more generic / self-contained than requiring developers to run an external script.

frank-dspeed commented 1 year ago

@sschuberth i make it even more generic i am working on a https://google.github.io/blockly-samples/plugins/block-dynamic-connection/test/ graalvm build tool ok it is not related to graalvm but it can build graalvm and that is in my view the most generic as it runs generic in my browser and is able to execute it directly else where or save it to a local file.

i simply connect my input processing and output blocks click run and call it a day and even get debug output if needed and so on. As also can edit on the fly if needed.

fniephaus commented 1 year ago

GraalVM has become more easily accessible in the last couple of months (e.g., SDKMAN!, GitHub Actions, script-friendly download URLs). It is also integrated in the Foojay API, which can be used by Gradle's toolchain detection.

Given this issue hasn't been updated for more than a year, I'm going to close it for now. In case you still see a problem or potentials for improvement, please speak up :)

cvmocanu commented 1 year ago

This should really be reopened. None of the variants listed allow for automatic management of the GraalVM SDK, or insures that all developers use same version for a particular project.