-
Notifications
You must be signed in to change notification settings - Fork 65
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
Evaluate jpackage to provide launchers #12
Comments
Note that it needs to run natively on each platform. |
I believe that is the same for building the native launchers. At least that is what I think I heard from @nnemkin in the past. |
Yes, native things (executables and shared libraries) must be built natively. I just mention it now because I'm not sure how equinox using jpackage to avoid having native launchers wouldn't then result in all downstream products needing to do the same thing, i.e., needing to do builds natively on each platform, which is not needed today when reusing the equinox-provided native launchers. |
jpackage is nice, but it's primary purpose is bundling the Java runtime and building native installers. Eclipse already has its own runtime bundles and installer. Equinox launcher has at least 6 features that need to be ported to Java or cut before it could be replaced:
|
This issue has been inactive for 180 days and is therefore labeled as stale. |
As discussion has shown jpackage would not benefit equinox launchers thus closing. |
jpackage is a new standard introduced with Java 14 to provide native launchers for Java applicatitions.
Example blog post about it: https://alvinalexander.com/java/how-use-jpackage-command-java-14-jdk-sdk/
Maybe we could also use this to provide our launchers? We already decided in the PMC to remove the support native splash loading via #19 but this might be another opportunity to reduce / remove the need for our own launcher.
The text was updated successfully, but these errors were encountered: