-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Switch the Gradle build to org.gradlex.java-module plugins #13401
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
base: main
Are you sure you want to change the base?
Conversation
…#13324) Co-authored-by: Oliver Kopp <kopp.dev@gmail.com> Co-authored-by: Siedlerchr <siedlerkiller@gmail.com>
...and remove some special case handling of MacOS
Sorry about the confusion with the portable version. This is indeed another use case not yet covered by the packaging plugin. But it is easy enough to add (gradlex-org/java-module-packaging#60). I made the change on the preview branch of the plugin we currently use in this PR. What we have now is: binaries are building, including mac signing, through Gradle. I made some changes to There are two follow up questions:
Yes that is the plugins default. if you do that you can remove these configuration lines:
Is there any other specific need for these that breaks with this change? Or can we do the same adjustments that were done to @koppor please take another look at this once you find the time and let me know if there is something still missing or is broken. I would like to make sure that we have everything we need in the packaging plugin before I prepare the next release. |
...to not produce artifacts - like zipped Jar-based distribution - we do not need.
Nice!
+1 for a follow-up PR.
No. We need to merge the EA workflow in this one - to avoid code duplication. Will be a block of fetching the JavaFX version and changing the JavaFX version in the versions build gradle file.
Yes
Yes (therefore also flagged as "Optional" :)) |
jabkit is CLI only. As far as I understood, dmg does not make sense here. Thus, I remove it directly after it was created. I also added file renaming for jabkit to be in line with JabRef (GU). Need to check after everything was build and uploaded to https://builds.jabref.org/pull/13401/merge |
With fix gradlex-org/java-module-packaging#61 it works (on Windows) Open points - can be fixed in a follow up Too many Java binariesDo we really need javac.exe distributed?
JabRef (GUI)✅ Portable application starts. I cannot do
This existed before, too. |
@trag-bot didn't find any issues in the code! ✅✨ |
The build of this PR is available at https://builds.jabref.org/pull/13401/merge. |
Tested on Arch Linux: downloaded build tarball for portable JabRef and run bin/JabRef Seems to work fine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happend here? On purpose or artifact?
At https://builds.jabref.org/pull/13401/merge, jabkit and the portable versions do not have the number 6.0 in their name. Is this intentional? |
Tested:Linux Mint 22.1 Cinnamon
|
Follow-up to #13324
TODOs
jabgui\build\tmp\jpackage\windows-2022\app-image\
?Execution failed for task ':jabkit:jpackageMacos-14'.
> java.lang.NullPointerException (no error message)
buildres/*
tosrc/main/resourcesPackage
. But there needs more to be adapted injavaModulePackaging {
Mandatory checks
CHANGELOG.md
described in a way that is understandable for the average user (if change is visible to the user)