search

fvarrui / JavaPackager

:package: Gradle/Maven plugin to package Java applications as native Windows, MacOS, or Linux executables and create installers for them.
GNU General Public License v3.0
1.07k stars 133 forks source link

Add compiled universalJavaApplicationStub as option #187

Closed AstroPixelProcessor closed 2 years ago

AstroPixelProcessor commented 2 years ago

I'm submitting a…

Short description of the issue/suggestion: Without using a binary of the universalJavaApplicationStub for macOS packaging, the java Swing JFileCHooser can not access the user's Documents/Downloads/Desktop folders. So I would suggest to add an option to Java-packager in which the user can choose whether to use a script or binary universalJavaApplicationStub. The binary should work always, the script can give issues with for instance JFileChooser. The binary does not an extra dependency: the shc shell compiler:

https://github.com/neurobin/shc

What is the expected behavior?

A working application that passes notarisation with hardened runtime codesigning and with a working JFileChooser.

What is the current behavior?

An application that passes notarisation with hardened runtime codesigning BUT without a working JFileChooser.

Please tell us about your environment:

I will submit a Pull Request with my suggestion ;-)

fvarrui commented 2 years ago

JavaPackager uses a modified version of universalJavaApplicationStub; here is the fork. I'm going to create a GitHub Action workflow to compile the script using shc, and then include this modified/compiled version with JavaPackager, adding an option to choose between the compiled or the interpreted version (to keep backward compatibility).

AstroPixelProcessor commented 2 years ago

@fvarrui , excellent, i used your forked universalJavaApplicationStub to test and cofirm it. I was not sure if the text conversion was needed or not from your version, so I did the compile after the text conversion in MacPackager.

Yes, it should be perfectly fine to have a precompiled stub ready in the resources/mac folder.

Making nice progress !

AstroPixelProcessor commented 2 years ago

I now have all my packaging working completely ready for distribution of my project:

You can add my project to your ReadMe as a project that depends on your javapackager: Astro Pixel Processor - https://www.astropixelprocessor.com/

Thanks to your javapackager I am now able to move my project from JDK8 with e(fx)clipse/ant packaging with the JDK8's packager to JDK17 building with maven dependencies (I can now provide a macOS native aarch64 version of my application, which is really great!)

Thank you very much for your work on this ;-) !

fvarrui commented 2 years ago

I now have all my packaging working completely ready for distribution of my project:

  • Windows with InnoSetup,
  • Linux DEB and RPM and
  • macOS DMG for x86_64 and for arm64 You can add my project to your ReadMe as a project that depends on your javapackager: Astro Pixel Processor - https://www.astropixelprocessor.com/

Thank you very much for your work on this ;-) !

Yes, of course. Thanks to you for helping to improve this tool

fvarrui commented 2 years ago

@fvarrui , excellent, i used your forked universalJavaApplicationStub to test and cofirm it. I was not sure if the text conversion was needed or not from your version, so I did the compile after the text conversion in MacPackager.

Yes, it should be perfectly fine to have a precompiled stub ready in the resources/mac folder.

Making nice progress !

Yes, you are right, the script is preprocessed before copying it to the bundle. But I have an idea. Add some new properties to Info.plist (name and relocateJar) that the script will read, and depending on that property, work one way or another, without the need to tune it.

fvarrui commented 2 years ago

I'm going to publish these changes in issue-187. When ready, I'll let you know!

AstroPixelProcessor commented 2 years ago

Great, look forward to it !

fvarrui commented 2 years ago

I've upgraded my universalJavaApplicationStub fork, and now a GitHub Action workflow generates and releases the compiled and the uncompiled version of the script. And now the script doesn't have to be preprocessed, as now it changes its behaviour based on Info.plist properties.

Next step: include both script versions as JavaPackager resources, and add a new property to the plugin what allow to choose which version has to be bundle with the app.

fvarrui commented 2 years ago

What if we include your entitlements.plist file as a JavaPackager resource, so it could be used by default if macConfig.entitlements property is not specified. What do you think about this?

AstroPixelProcessor commented 2 years ago

Hi @fvarrui excellent, just so I understand this, the compiled script will still be dynamic based on the Info.plist properties? That is really great ;-)

I agree, both the script .sh and the compiled binary should be available. You can even make a universal binary that includes x86_64 and aarch64 binaries if Github can compile for both targets? Like: https://github.com/tofi86/universalJavaApplicationStub/pull/119/commits/bc612367161794a19b8230c2a437cb45f09939ca I have tested this and it works perfectly. It ensures that the compiled version will run on all platforms today, but also in the future when Apple might not include support for x86_64 in the compiler at some point ?

"What if we include your entitlements.plist file as a JavaPackager resource" Yes, for sure, I think it will help many to get started quickly without encountering problems with their apps not running... These runtime exception entitlements are quite important to be able to run java apps properly while having the hardened runtime enabled in signing which is a must for notarization to be accepted by Apple. And then refer in your ReadMe to what these entitlements mean relating to codesiging : https://developer.apple.com/documentation/security/hardened_runtime

fvarrui commented 2 years ago

Changes released to issue-187. New property macConfig.macStartup = SCRIPT|UNIVERSAL|X86_64|ARM64 to choose between differente type of startups. Default entitlements.plist file when not scpecified.

Not tested yet!

EasyG0ing1 commented 2 years ago

@fvarrui

Changes released to issue-187. New property macConfig.macStartup = SCRIPT|UNIVERSAL|X86_64|ARM64 to choose between differente type of startups. Default entitlements.plist file when not scpecified.

Not tested yet!

How do I test this? Did you push it to the repository?

AstroPixelProcessor commented 2 years ago

@fvarrui do you need me to test it ? I will see if I can do this today or tomorrow ;-)

fvarrui commented 2 years ago

@fvarrui

Changes released to issue-187. New property macConfig.macStartup = SCRIPT|UNIVERSAL|X86_64|ARM64 to choose between differente type of startups. Default entitlements.plist file when not scpecified. Not tested yet!

How do I test this? Did you push it to the repository?

Hi @EasyG0ing1! Just follow next steps to install JavaPackager 1.6.7-SNAPSHOT to your local Maven repo:

git clone https://github.com/fvarrui/JavaPackager --branch issue-187
cd JavaPackager
./gradlew publishToMavenLocal
fvarrui commented 2 years ago

@fvarrui do you need me to test it ? I will see if I can do this today or tomorrow ;-)

Yes ... great, thanks! I've just tested with SCRIPT, X86_64 and UNIVERSAL, and default entitlements, and all seems to be working fine. But your feedback will be welcomed!

fvarrui commented 2 years ago

Branch issue-187 merged into devel.

kerner1000 commented 2 years ago

I now have all my packaging working completely ready for distribution of my project:

  • Windows with InnoSetup,
  • Linux DEB and RPM and
  • macOS DMG for x86_64 and for arm64

You can add my project to your ReadMe as a project that depends on your javapackager: Astro Pixel Processor - https://www.astropixelprocessor.com/

Thanks to your javapackager I am now able to move my project from JDK8 with e(fx)clipse/ant packaging with the JDK8's packager to JDK17 building with maven dependencies (I can now provide a macOS native aarch64 version of my application, which is really great!)

Thank you very much for your work on this ;-) !

Hi there, may I ask how to bundle both aarch64 and x86_64?

fvarrui commented 2 years ago

JavaPackager v1.6.7 released to Maven Central. See changes here.

kerner1000 commented 2 years ago

Hello @AstroPixelProcessor , Do you package a JRE into your Bundle? If so, how do change the embedded CFBundleIdentifier inside the java binary?

fvarrui commented 2 years ago

I now have all my packaging working completely ready for distribution of my project:

  • Windows with InnoSetup,
  • Linux DEB and RPM and
  • macOS DMG for x86_64 and for arm64

You can add my project to your ReadMe as a project that depends on your javapackager: Astro Pixel Processor - https://www.astropixelprocessor.com/ Thanks to your javapackager I am now able to move my project from JDK8 with e(fx)clipse/ant packaging with the JDK8's packager to JDK17 building with maven dependencies (I can now provide a macOS native aarch64 version of my application, which is really great!) Thank you very much for your work on this ;-) !

Hi there, may I ask how to bundle both aarch64 and x86_64?

Sorry, I miss this question. It's not possible if you bundle a JRE with your app, as it's compiled for an specific system architeture. Otherwise, you can set macStartup=SCRIPT|UNIVERSAL

fvarrui commented 2 years ago

I think @AstroPixelProcessor can throw more light than me about this.