Skip to content
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

Duplicate data in packages produced by jpackage #51

Closed
nemphys opened this issue Apr 14, 2019 · 9 comments
Closed

Duplicate data in packages produced by jpackage #51

nemphys opened this issue Apr 14, 2019 · 9 comments

Comments

@nemphys
Copy link

nemphys commented Apr 14, 2019

I tried making a macOs .app using the jpackage functionality for the first time and, although all went well and the app works as expected, the total size of the app directory is 1.5x the size it should be (the jlink task produces a total size of ~100MB in my case, whereas the .app is ~150MB).
After checking the contents of the .app I noticed something weird:
apart from the Plugins/Java.runtime directory (which seems to include all of the jlink task results), there is a Java/mods directory, which includes separate jar files + the merged module file. If I understand correctly, all these jars are already merged inside the "modules" file residing in the libs directory (Plugins/Java.runtime/contents/home/lib) of the runtime image produced by jlink.
Although I prefer to have separate jars than the huge uber-merged modules file produced by jlink (this is another discussion, I would love to have some more info on this and whether it is optional), there seems to be some kind of duplication here.
Any thoughts would be appreciated.

EDIT: I just deleted the Java/mods directory from the produced .app and the app still launches and works fine. This verifies that the directory is unneeded and I am wondering why it is being produced. I suspect it is a jpackage thing and the badass plugin has nothing to do with it.

@siordache
Copy link
Member

Yes, it looks like a jpackage thing.

@msgilligan
Copy link

Should we report this issue to jpackage?

@DJViking
Copy link
Collaborator

DJViking commented Sep 19, 2019

If this is still an issue we should report it to jpackage on core-libs-dev@openjdk.java.net
Have you tried with the latest JDK-14 jpackage build if this is still a problem? https://jdk.java.net/jpackage

I cannot see that this is a reported bug with jpackage:
https://bugs.openjdk.java.net/issues/?jql=project+in+%28JDK%29+AND+component+in+%28tools%29+AND+Subcomponent+in+%28jpackage%29

@tobiasdiez
Copy link
Contributor

The two issues https://bugs.openjdk.java.net/browse/JDK-8236830 and https://bugs.openjdk.java.net/browse/JDK-8249011 were closed with the argument that this folder is only included if jpackage is invoked with the wrong arguments, i.e. jpackage includes everything that is in the folder passed as --input. So I guess the problem does lie in this gradle plugin and how it invokes jpackage.

@siordache
Copy link
Member

Please check and report if duplicate data is still produced when using org.beryx.jlink 2.21.1.

@tobiasdiez
Copy link
Contributor

Thanks a lot! It worked for us and reduced the installer size by almost 50%.

@nemphys
Copy link
Author

nemphys commented Jul 27, 2020

Indeed, it seems that the issue is now resolved.
Thank you.

@nemphys nemphys closed this as completed Jul 27, 2020
@siordache
Copy link
Member

Great! Thank you both for the feedback.

@msgilligan
Copy link

Thanks for this. It's saves about 9-10 Mb (after compression) in a trivial app:
Before:

BA_JLink_2_21_0
After:

BA_JLink_2_21_1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants