Description
As said in the forum,
https://forum.mediathekview.de/topic/3116/inoffizielles-mv-13-5-1-paket-f%C3%BCr-win-32-bit-tester-gesucht
I tried to compile MV for Win32 and for linux-arm32
https://forum.mediathekview.de/topic/3105/darstellungsfehler-und-ausnahmen-unter-raspbian-auf-raspberry-pi-4/22
While of course testing of these builds is a completely different thing and nothing that I ask of you, maybe you could befriend with three according adjustments the pom.xml. All of them regarding dependency entries for JavaFX or according properties respectively
-
use a property for groupId of each JavaFX dependency rather than repeating the text org.jfx for each dependency element
-
add a tag
<type>to each JavaFX dependency -
use a property for that tag packaging type of each JavaFX dependency, see 2)
While reading the according dependency section may become more complex that way, I think, maintaining it would be not. So I hope it's not too unconvenient for official maintainers.
I see benefits in a change like that, though:
ad 1) reducing JavaFX artifacts' groupId to 1 actual occurance will make it easy to consistently swap to a different maven repository. Namely, support import from dependencies that are available in the local maven repository only. Consider somebody having a local JavaFX package for platforms that are not listed in org.javafx
ad 2) while packaging type seemingly defaults to type "jar", with Java 9 this no longer seems to be the only types that can be thought of: Now there is type "jmod" (Java module), also. With type in the JavaFX dependency elements, one would not be restricted to jar sources any longer but could also use jmod sources. Consider e.g. https://github.com/khmarbaise/jdk9-jlink-jmod-example/blob/master/maven-example/mod-jlink/pom.xml
ad 3) this would simplify making consistent changes of packaging type
So, why all this fuzz? What's behind that story?
Because some OpenJDK editions are shipped that way. Consider Liberica https://bell-sw.com/pages/java-13.0.2/ or Zulu https://www.azul.com/downloads/zulu-community/?&package=jdk-fx
At least these two do come with JavaFX. With this, there is a subfolder "./jmods/" with, among others, Java modules javafx.base.jmod, javafx.controls.jmod, javafx.fxml.jmod, javafx.graphics.jmod, javafx.media.jmod, javafx.swing.jmod, javafx.web.jmod.
A programmer can actually import these jmod files to his local maven repository...
...and use them as dependency for his projects' pom.xml files.
As a newbie to Maven and JMod and MV src: When investigating MV 32-bit builds, I had a simple Hello World application to understand how I could to this.
https://github.com/me-like-cookies/TestStuff/tree/master/mvnusejmod
After that Hello World, it was not such a big deal to get MV src to compile with locally installed JavaFX jmod packages targetted for platforms that are officially not even supported by MV. e.g. Win32 and linux-arm. - with as much as changing 4 properties of the original pom.xml: groupId, version, classifier, type.
Please let me know if you are interested in that suggestion. If you want me to, I could prepare a PR for pom.xml for branch develop. Of course, If you like I could also provide my (windows) script to quickly install a new OpenJDK version's jmod files, and add an according section to the instruction to get MV compiled from scratch.
While I have no Raspberry Pi and have no idea of QEMU or other ARM simulators for my amd64 host, maythe this could help some people to get MV to their own devices, by using other JavaFX sources than org.openjfx from public maven repositories
This is not a request to support other platforms, it's a suggestion to simplify building for that platforms.