substrate
substrate copied to clipboard
gluonhq
Provision GraalVM when not provided by user
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.
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>
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:
- to install graal from graalvm.org
- how he can configure substrate to point to an existing graal installation on his system
In order from best to worst scenario:
- 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)
- Substrate doesn't detect a valid version of GraalVM in $GRAALVM, and downloads a relevant one.
- 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.
We already implemented this flow, so this issue can be closed, @johanvos ?
No, this flow is not implemented at all within substrate. It is currently implemented by the client-maven-plugin.
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?
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 ;) )