Switch to gradlex for modularity

[koppor]

Fixes https://github.com/JabRef/jabref-issue-melting-pot/issues/919

• Removes gradle-modules-plugin, which I needed to patch: Add usage of java Command-Line Argument File on Windows java9-modularity/gradle-modules-plugin#282
• Removes org.openjfx.javafxplugin

Replaces all by better alternatives

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.

[jjohannes]

The opensTo here is oriented at what you can do in module-info.java files and not at the command line. The idea is to have this "block" look similar to how you would write a module-info.java if it were possible for whitebox tests.

The opensTo opens all packages of this test module (tests of org.jabref.jablib) to another module.

E.g. by default the plugin already does opensTo.add("org.junit.platform.commons").

You can consistently open packages in the existing modules javafx.base of javafx.fxml by patching them. See my comment here.

[trag-bot]

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

[koppor]

Tried out locally - works.

[trag-bot]

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

[github-actions]

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

[calixtus]

Can this be moved to common build.gradle.kts or is the variable unreachable then?

[koppor]

Juli(a)?

[koppor]

IDK if dependabot will know it then...

[Siedlerchr]

After a clean, I now get issues on macOS (m1, arm) with run
It seems like it downloads the wrong javafx version because we don't have the classifier:
implementation("org.openjfx:javafx-base:$javafxVersion:mac-aarch64")
this is what the openjfx plugin does

@jjohannes You use a mac as well, do you have a hint? Do we need to readd the openjfx plugin?

2025-06-02 21:29:21 [JavaFX-Launcher] sun.util.logging.internal.LoggingProviderImpl$JULWrapper.log()
WARN: Unsupported JavaFX configuration: classes were loaded from 'module javafx.graphics', isAutomatic: false, isOpen: true
Loading library prism_es2 from resource failed: java.lang.UnsatisfiedLinkError: /Users/christophs/.openjfx/cache/24.0.1+4/aarch64/libprism_es2.dylib: dlopen(/Users/christophs/.openjfx/cache/24.0.1+4/aarch64/libprism_es2.dylib, 0x0001): tried: '/Users/christophs/.openjfx/cache/24.0.1+4/aarch64/libprism_es2.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/christophs/.openjfx/cache/24.0.1+4/aarch64/libprism_es2.dylib' (no such file), '/Users/christophs/.openjfx/cache/24.0.1+4/aarch64/libprism_es2.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64'))

build:

[koppor]

Maybe we need to partially revert 3f3e38e (#13112)?

I think, this is the snippet:

build-logic/src/main/kotlin/buildlogic.java-common-conventions.gradle.kts

+ val arch = System.getProperty("os.arch")
+ val javafxPlatform = when {
+     os.isWindows -> "win"
+     os.isMacOsX && arch == "aarch64" -> "mac-aarch64"
+     os.isMacOsX -> "mac"
+     os.isLinux && arch == "aarch64" -> "linux-aarch64"
+     os.isLinux -> "linux"
+     else -> error("Unsupported OS/arch: ${os.name} / $arch")
+ }

+ project.extra["javafxPlatform"] = javafxPlatform

(and in multiple files)

+    implementation("org.openjfx:javafx-base:$javafxVersion:$javafxPlatform")
+    implementation("org.openjfx:javafx-controls:$javafxVersion:$javafxPlatform")
+    implementation("org.openjfx:javafx-fxml:$javafxVersion:$javafxPlatform")
+    // implementation("org.openjfx:javafx-graphics:24.0.1:win")
+    implementation("org.openjfx:javafx-graphics:$javafxVersion:$javafxPlatform")
+    implementation("org.openjfx:javafx-swing:$javafxVersion:$javafxPlatform")
+    implementation("org.openjfx:javafx-web:$javafxVersion:$javafxPlatform")
-    implementation("org.openjfx:javafx-base:$javafxVersion")
-    implementation("org.openjfx:javafx-controls:$javafxVersion")
-    implementation("org.openjfx:javafx-fxml:$javafxVersion")
-    // implementation("org.openjfx:javafx-graphics:24.0.1")
-    implementation("org.openjfx:javafx-graphics:$javafxVersion")
-    implementation("org.openjfx:javafx-swing:$javafxVersion")
-    implementation("org.openjfx:javafx-web:$javafxVersion")
``´

[Siedlerchr]

Yeaht that seems like the best option

[jjohannes]

@Siedlerchr @koppor hi. No need to revert this. The issue is in the OS detection code. This:

jabref/build-logic/src/main/kotlin/buildlogic.java-common-conventions.gradle.kts

Lines 40 to 41 in 4f1b9fc

	val osVersion = System.getProperty("os.version")
	if (osVersion.startsWith("14")) "macos-14" else "macos-13"

Should be something like this:

        val arch = System.getProperty("os.arch")
        if (arch.contains("aarch")) "macos-14" else "macos-13"

The names for the targets are taken from the current GitHub hosted runner names. macos-14 is ARM. I think that caused confusion. You can change the names of the targets to something "clearer" if you like.

(Note: Based on your feedback, this OS detection may work out of the box in the future - gradlex-org/java-module-packaging#51)