Skip to content

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

Open
wants to merge 29 commits into
base: main
Choose a base branch
from

Conversation

koppor
Copy link
Member

@koppor koppor commented Jun 24, 2025

Follow-up to #13324

TODOs

Mandatory checks

  • I own the copyright of the code submitted and I license it under the MIT license
  • [/] Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
  • [/] Tests created for changes (if applicable)
  • Manually tested changed features in running JabRef (always required)
  • [/] Screenshots added in PR description (if change is visible to the user)
  • [/] Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
  • [/] Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

…#13324)

Co-authored-by: Oliver Kopp <kopp.dev@gmail.com>
Co-authored-by: Siedlerchr <siedlerkiller@gmail.com>
@koppor koppor added the dev: binaries Binary builds should be uploaded to builds.jabref.org label Jun 24, 2025
@koppor koppor changed the title Switching the Gradle build to org.gradlex.java-module plugins Switch the Gradle build to org.gradlex.java-module plugins Jun 24, 2025
@jjohannes
Copy link
Collaborator

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 binaries.yml to do the Mac build similar to the others. I am not sure if that is all correct. Please check and please test the results.

There are two follow up questions:

  1. The mac command line build contained a few --java-options for jabgui. I did not find them in the Gradle build of jabgui, but found some similar options in the build for jabkit. It does not look like this discrepancy is on purpose. (Maybe something was lost with the Gradle changes already merged?). In any case, I added all the options to jabkit/build.gradle.kts which means they are applied to all targets (not only macos). Please verify if this is correct.
  2. The current portable version contains two scripts in bin: This is not a jlink feature, but a feature of the jlink plugin - LaunchScriptGenerator.groovy. Are these just there, because the plugin adds them or are they actually used/expected by users? If yes, I can add the behavior of generating these scripts directly to the build. I can do that, I just want to clarify first if it is needed.
    jkit

Optional: As far as I understand, we can move directories buildres/* to src/main/resourcesPackage.

Yes that is the plugins default. if you do that you can remove these configuration lines:
jpackageResources = layout.projectDirectory.dir("buildres")
But that is a detail which I would do in a follow up if you want. You can also keep it as it is.


bring back JavaFX EA builds

Is there any other specific need for these that breaks with this change? Or can we do the same adjustments that were done to binaries.yml once that is working? In any case, if you can live without the EA builds for some time, you could probably do the update in a follow up PR to speed things up.


@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.
@koppor
Copy link
Member Author

koppor commented Jun 29, 2025

Optional: As far as I understand, we can move directories buildres/* to src/main/resourcesPackage.
Yes that is the plugins default. if you do that you can remove these configuration lines: jpackageResources = layout.projectDirectory.dir("buildres")

Nice!

But that is a detail which I would do in a follow up if you want. You can also keep it as it is.

+1 for a follow-up PR.

bring back JavaFX EA builds
Is there any other specific need for these that breaks with this change?

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.

Or can we do the same adjustments that were done to binaries.yml once that is working?

Yes

In any case, if you can live without the EA builds for some time,

Yes (therefore also flagged as "Optional" :))

@koppor
Copy link
Member Author

koppor commented Jun 29, 2025

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

@koppor
Copy link
Member Author

koppor commented Jun 30, 2025

With fix gradlex-org/java-module-packaging#61 it works (on Windows)

Open points - can be fixed in a follow up


Too many Java binaries

Do we really need javac.exe distributed?

 Directory of C:\git-repositories\JabRef\jabkit\build\packages\windows-latest\jabkit\runtime\bin

30.06.2025  14:18            47.280 jabswitch.exe
30.06.2025  14:18           109.224 jaccessinspector.exe
30.06.2025  14:18            73.064 jaccesswalker.exe
30.06.2025  14:18            25.600 jar.exe
30.06.2025  14:18            25.600 jarsigner.exe
30.06.2025  14:18            51.928 java.exe
30.06.2025  14:18            25.600 javac.exe
30.06.2025  14:18            25.600 javadoc.exe
30.06.2025  14:18            25.600 javap.exe
30.06.2025  14:18            51.928 javaw.exe
30.06.2025  14:18            25.600 jdb.exe
30.06.2025  14:18            25.600 jdeprscan.exe
30.06.2025  14:18            25.600 jdeps.exe
30.06.2025  14:18            25.600 jfr.exe
30.06.2025  14:18            25.600 jimage.exe
30.06.2025  14:18            25.600 jlink.exe
30.06.2025  14:18            25.600 jmod.exe
30.06.2025  14:18            25.600 jnativescan.exe
30.06.2025  14:18            25.600 jpackage.exe
30.06.2025  14:18            25.600 jrunscript.exe
30.06.2025  14:18            25.600 jshell.exe
30.06.2025  14:18            25.600 jstatd.exe
30.06.2025  14:18            25.600 keytool.exe
30.06.2025  14:18            25.600 kinit.exe
30.06.2025  14:18            25.600 klist.exe
30.06.2025  14:18            25.600 ktab.exe
30.06.2025  14:18            25.600 rmiregistry.exe
30.06.2025  14:18            25.600 serialver.exe
              28 File(s)        922.224 bytes

JabRef (GUI)

✅ Portable application starts.

I cannot do --help.

Error: Option [--win-console] is not valid with type [msi]

This existed before, too.

@koppor koppor added the status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers label Jun 30, 2025
Copy link

trag-bot bot commented Jun 30, 2025

@trag-bot didn't find any issues in the code! ✅✨

Copy link
Contributor

The build of this PR is available at https://builds.jabref.org/pull/13401/merge.

@InAnYan
Copy link
Member

InAnYan commented Jun 30, 2025

Tested on Arch Linux: downloaded build tarball for portable JabRef and run bin/JabRef

Seems to work fine

Copy link
Member

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?

@ThiloteE
Copy link
Member

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?

@ThiloteE
Copy link
Member

ThiloteE commented Jun 30, 2025

Tested:

Linux Mint 22.1 Cinnamon

  • Linux kernel 6.8.0-62-generic
  • cinnamon-version 6.4.8
  • ✅ JabRef-portable_linux.tar.gz via /bin/JabRef. Seems to work fine.
  • JabRef_6.0.deb (maybe somebody can test this with a vagrant virtual machine?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dev: binaries Binary builds should be uploaded to builds.jabref.org status: ready-for-review Pull Requests that are ready to be reviewed by the maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants