-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
About GraalVM #408
Comments
Hi @EasyG0ing1! |
@fvarrui Looks like GraalVM does not have any tools to make installers. But, with a little poking around, it looks like Platypus - for example - can package native-images into an .app package. I just tested this and it works. I also created a pkg installer for that .app package using I'm thinking (and I'm saying this out of ignorance - not knowing exactly how JP does what it does) that in terms of making a native image with JP, we could start by leveraging GraalVM for simple use cases ... maybe even devote a dedicated section to the execution portion of the POM settings for JP. Since creating native images is not an "A:install" kind of process, it would be more interactive for the developer to use. For example, when you use the java command with the right argument that causes a jar file to be executed while Graal monitors the use of the app to generate the config files would be something that needs some consideration in terms of how you would include that ability into JP. Because that's a step in the process that can't usually be avoided and yet its a step that makes a one time run of compilation impossible because the config files need to be generated before the native-image can be created ... so it's going to require documentation that's a little more involved than any of the docs you have now and it's going to require some means of interacting with JP doing things in two steps. Perhaps having those settings in one section where that step is engaged with a different mvn argument than what they would use when making the actual native-image... Some thought needs to go into the process and a determination needs to be resolved for how the user will trigger the processes. It's certainly more involved I think than how people use JP now though I don't think it needs to be very complicated either. Allowing users to engage the tool where certain POM file options trigger the right command line switches on the back end run will of course be a big part of integrating this into JP. I do see it being useful in a project like JP ... it would be nice to be able to have a single place to define the graal stuff where now I'm having to do that using different bash scripts and that gets to be somewhat of a pain to manage especially when dealing with multiple operating systems. |
I can now use GraalVM to package it into an .exe file. Currently, I need to package the .exe file and related resource files into a self-extracting package for others to install and use. Can it be achieved with javaPackager? Are there any examples? |
There were plans to integrate GraalVM with JP, but not enough time 😞 In addition, a long time ago I was researching warp (#216), which allows you to create self-extracting executables (portable apps) for all platforms. Right now it's not supported by JP, but you could try it. Another plan for JP was to split the plugin into several smaller plugins, so that you can use only the parts of JP that you need in your build process. This would be great to be able to generate only the installer from your already generated application. But we return to the same point, lack of time, sorry!! 😢 |
I've been compiling native-images both with standard Java programs and JavaFX and have compiled some useful notes that might help you when trying to add graal support into JP.
The text was updated successfully, but these errors were encountered: