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

Use JRE for binaries instead of JDK #2681

Open
HenrikJannsen opened this issue Aug 25, 2024 · 7 comments
Open

Use JRE for binaries instead of JDK #2681

HenrikJannsen opened this issue Aug 25, 2024 · 7 comments

Comments

@HenrikJannsen
Copy link
Contributor

Currently we package the same JDK version used for the build into the binaries. We should use the JRE (of same java and vendor version) instead to safe about 60 MB on file size.

The BisqToolchainResolver would need an extension to be used for the packager. The download path is exact the same just jdk will be jre.

The getJPackageJdkDirectory method in PackagingPlugin delivers the path for the runtime. This would require changes to support the JRE.

@HenrikJannsen
Copy link
Contributor Author

@alvasw Do you see any issues with that?
@rodvar Would you be interested to work on that?

@rodvar
Copy link
Contributor

rodvar commented Aug 26, 2024

sure @HenrikJannsen I can have a look!

@rodvar
Copy link
Contributor

rodvar commented Aug 30, 2024

starting work on this one

@rodvar
Copy link
Contributor

rodvar commented Aug 30, 2024

@HenrikJannsen just did some initial tests, it looks like this is as easier as changing the urls to use jre instead of jdk.
zulu doesn't have any specific subdirs for jre, so no need to change the Packaging plugin.

The download size is significant, but the final binaries doesn't get much of an improvement... shall I send a PR to discuss anyways?

@rodvar
Copy link
Contributor

rodvar commented Aug 31, 2024

@HenrikJannsen just did some initial tests, it looks like this is as easier as changing the urls to use jre instead of jdk. zulu doesn't have any specific subdirs for jre, so no need to change the Packaging plugin.

The download size is significant, but the final binaries doesn't get much of an improvement... shall I send a PR to discuss anyways?

clarified the above on a matrix chat.
We need to keep the JDK resolver as is, but the idea is to build a new JRE resolver and set it up in the jpackager to be used for binaries (as opposed to let it use the jdk bins as it is now

@alejandrogarcia83
Copy link
Contributor

I have to revert PR #2773 because the changes broke the release tasks. The release has been already delayed by more than a week and I don't want to delay the release further.

@rodvar
Copy link
Contributor

rodvar commented Oct 12, 2024

Hi @alejandrogarcia83 , I'm surprised and sorry to hear that, saw you comment as well in #2773 (comment)

Could you please be more specific, which release tasks were broken? Do you have any logs? I'm happy to give you a hand to fix this so we can include this substantial size improvement for the next release hopefully.

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

No branches or pull requests

3 participants