gluonhq / substrate

Create native Java(FX) apps for desktop, mobile and embedded
GNU General Public License v2.0
389 stars 52 forks source link

Provision GraalVM when not provided by user #34

Open tiainen opened 4 years ago

tiainen commented 4 years ago

When the graalvm system property is not provided, substrate must download a hardcoded version of GraalVM for the host platform. The downloads can be found at https://download2.gluonhq.com/substrate/graalvm/graalvm-unknown-java11-19.3.0-dev-gvm-3-${host}.zip where ${host} should be replaced with linux-x86_64 or darwin-amd64.

abhinayagarwal commented 4 years ago

I am hit by the same issue. Made some changes in Client Maven plugin to use substrate. While executing mvn client:compile, the execution is halted due to the following issue:

Error: Cannot run program "null/bin/native-image": error=2, No such file or directory

This can be fixed by adding the following in the configuration part of the plugin:

<graalLibsPath>
$HOME/.gluon/substrate/graalvm/graalvm-unknown-java11-19.3.0-dev
</graalLibsPath>
tiainen commented 4 years ago

The ultimate goal is that substrate uses an official version of Graal that the user has installed from the GraalVM website.

I think this issue should instead be that substrate must try and find a Graal installation. If it can't, it should fail with a message telling the user:

johanvos commented 4 years ago

In order from best to worst scenario:

  1. GraalVM is installed on the developer's system, and $GRAALVM points to the installation (This requires that GraalVM 19.0.3 has all the required changes for mobile, and there might be 1 or 2 PR's missing)
  2. Substrate doesn't detect a valid version of GraalVM in $GRAALVM, and downloads a relevant one.
  3. The plugin tells Substrate which version of GraalVM to use (which can be "version nr" or "download URL"

I see 3. as the least important. Without the plugin specifying anything, this should still work.

jperedadnr commented 4 years ago

We already implemented this flow, so this issue can be closed, @johanvos ?

tiainen commented 4 years ago

No, this flow is not implemented at all within substrate. It is currently implemented by the client-maven-plugin.

jperedadnr commented 2 years ago

Downloading GraalVM is a lengthy process, and I still think we don't need to download GraalVM if GRAALVM_HOME is not set. For instance, it has been defined, but the IDE doesn't have access to the system env vars...

@tiainen do you think we should still try to download at all cost?

johanvos commented 2 years ago

It's an almost 400MB download, so I agree we should not do that unconditionally (and give users like me who forgot to set GRAALVM_HOME a chance to set that ;) )