Closed ghost closed 4 years ago
The JMod stuff comes from the new module system which comes along with Java 9. We aren't actually on a point where it would be a good idea to switch to the new module system. Your point with just use properties to reduce the boilerplate sounds good, I'll check that later. Actually install4j loads the jdk/jre we ship with MediathekView after a quick look into their documentation I saw it's (now?) possible to use Liberica as the JRE provider. If I understand it right Liberica includes JavaFX already so we don't have to include it. So it should be possible to remove the JavaFF stuff from packing so it's only available for compiling. I'll try this later :)
It will not be removed from as it is needed on macOS and Linux for bugfixes. There is a reason why javafx is at 14 EA instead of the released versions. There are bugs on macOS which cause the app to freeze and on KDE to improperly display dialogs
Yeah right @derreisende77. I missed that point sorry. Then I'll leaf the JFX in the packaging and only remove it for the 32 bit versions.
@Nicklas2751 pardon my English. I did not intend to suggest switching MV target to JMod. My intention was to allow using JMod as an alternative source, restricted to JavaFX dependencies.
For my Win32 Build, I 1) downloaded Liberica OpenJDK (or Zulu JDK+FX) 11 for Win32 2) extracted downloads to
C:\OpenJDK\bellsoft-jdk11.0.6-win_i586
C:\OpenJDK\zulu-jdk11.0.5-win_i686
3) used my script to import C:\OpenJDK\bellsoft-jdk11.0.6-win_i586\jmods\javafx*.jmod
to my local maven repository.
mvn install:install-file
-Dfile=C:\OpenJDK\bellsoft-jdk11.0.6-win_i586\jmods\javafx.base.jmod
-DgroupId=local.openjdk # see below, 4)
-DartifactId=javafx-base
-Dversion=11.0.6-Bellsoft+
-Dclassifier=win32
-Dpackaging=jmod # this is the place that I had intended to refer to by "packaging"
4) changed MV pom.xml to use locally installed jmod for build rather than locally "buffered" jar from remote org.openjfx
<dependency>
<groupId>local.openjdk</groupId> #see above, 3)
<artifactId>javafx-base</artifactId>
...
<type>jmod</type>
</dependency>
The little I, as a rookie, understand of maven's pom.xml here is: it seems to default dependency type to jar. And my suggestion is to explicitly set type. Use
The build of MV of course may target jar; I only tried to find a way to use the givens of the OpenJDK packages for my inofficial build.
And of course: adjusting pom.xml if/when I build another MV for target Win32, I can as well change 11 lines and add 7x <type>jmod</type>
and not only change 4 parameters.
@me-like-cookies du darfst hier auch in deutsch schreiben. Jeder im Projekt kann deutsch ;)
I created a branch „feature/32bit“ with my actual changes. The results are these: https://p.elaon.de/m-jnL/
Can you please try to test them? I will test them too but hadn‘t the time today to create a 32 bit VM.
Na dann eben Deutsch @alex1702.
@Nicklas2751 Von wegen Testen. Ich hab nach meinem Post mit dem inoffiziellen Build meinen alten Desktop neu installiert und hab jetzt ein Win32 Blech (x86-64 Prozessor mit 32-Bit Betriebssystem halt nämlich Win 10 Pro 1909). Win32 VM aufm Desktop hab ich nicht. Muss ich immer Monitore umstecken... Bei Zulu hab ich gelesen, dass die mindestens Windows Server 2008 voraussetzen oder Windows 8 - Windows 7 hat eine zu geringe .NET Version. Andererseits haben Windows 7 Nutzer inzwischen andere Probleme als fehlende MV Updates methinks. Bei Liberica habe ich keine Hinweise auf minimale NT-Version gefunden.
Eine debian i586 VM sollte von neulich noch aufm Desktop liegen.
Das kann ich beides anschauen.
QEMU hab ich zwar mal installiert, aber hab mich nicht reingefünferlt, wie man einen RPi emulieren kann. und ein RPi Blech hab ich auch keines. Momentan brauch ich eher weniger neue Dinge, von denen ich keine Ahnung habe als noch mehr davon...
@Nicklas2751 Deine Test Builds Schau ich dann die Tage mal, kann Wochenende werden. Stehe im Moment mit Java auf Kriegsfuß und fruste mich nicht gerne zusätzlich nach Feierabend auch noch damit. Beziehungsstatus "es ist kompliziert".
Mit den Änderungen an der pom.xml gehst Du einen Weg, den ich mangels Maven Kenntnisse bisher gar nicht angedacht hatte, wie es scheint. Du nutzt https://repo1.maven.org/maven2/org/openjfx/javafx-base/14-ea+7/javafx-base-14-ea+7-sources.jar etc. zum compile gegen die JavaFX Klassen in Major-Version 14... ...und dann zur Laufzeit soll das verwendete JDK 11 bzw. JDK 13 selbst die benötigten Abhängigkeiten mitzubringen... wenn ich es richtig verstehe.
Hm. So lange es funktioniert, ok. Ich melde dann Erfolg / logs wenn ich teste.
Bei Liberica hatte ich mit "meiner" Methode, die mitgelieferten jmod im lokalen maven repo als Abhängigkeit einzubauen übrigens für Linux i586 keinen Erfolg, da für diese Plattform eben keine .jmod mitgeliefert werden. (11.0.5 und 11.0.6) Aber das seh ich dann ja, ob Deine Methode funktioniert. Verstehen brauch ich ja nicht, was passiert. Staunen und wundern genügt...
Bei meinen Builds von gestern haben die JavaFX module in der Angabe gefehlt so, dass diese nicht in der JRE enthalten waren. Hab das geändert und neu gebaut: https://p.elaon.de/m-jnL/
In meiner Windows 8 32 Bit VM hat jedenfalls alles funktioniert.
Hallo @Nicklas2751 ich hab grad mein Win32 Blech angeschaltet, mich remote eingeloggt und Deine Dateien für Win32 gezogen (2020-01-22-18-05 MET): Name: MediathekView_windows-x32_13_6_0-SNAPSHOT.zip Größe: 97828249 Bytes (93 MiB) SHA256: 90341410F97DDFC7098E98A71FE5285371FB00E84A57D12340D72A78BC0128C1 MD5: 0fff740a118012773ed16e06693f65f3 Name: MediathekView_windows-x32_13_6_0-SNAPSHOT.exe Größe: 70887424 Bytes (67 MiB) SHA256: 99184B9E62F73465A2F7B96B0E5D04BC2F7A2EE8903238C367BA2E04BD895B20 MD5: a1d3ed5f7d24fd79f8b6f1bef34a3de5
Mir fallen ein paar Sachen auf:
ffmpeg.exe ist in .zip und .exe ... sind 133B dummies.
in der .zip funzt der Starter.
Aber es kommt in error.log ein guter alter Bekannter:
Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: class impl.org.controlsfx.behavior.RangeSliderBehavior (in unnamed module @0x13e9963) cannot access class com.sun.javafx.scene.control.inputmap.InputMap$Mapping (in module javafx.controls) because module javafx.controls does not export com.sun.javafx.scene.control.inputmap to unnamed module @0x13e9963
at impl.org.controlsfx.behavior.RangeSliderBehavior.
Leider kann ich im Task-Manager nicht sehen, welche Parameter an die Java VM gegeben wurden. Im mediathekview.log sehe ich auch nichts. Jedenfalls behelfe ich mir in dieser Sache wie ebd. gesagt erfolgreich mit einemTipp aus https://stackoverflow.com/questions/51708581/issues-with-rangeslider-from-controlsfx und rufe java mit diesem Parameter auf --add-exports javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED
zur .exe Datei
zum Schluss fürs Erste noch ein diff des entpackten zip und des per .exe Installierten MV (mittels Winmerge) Vergleiche c:\zip mit C:\inst 22.01.2020 19:07:17 Dateiname,Ordner,Vergleichsergebnis,Linkes Datum,Rechtes Datum,Erweiterung
.install4j,,Ordner sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:10:40,
autoUninstall.1,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:40,1
build.uuid,.install4j,Nur Links: c:\zip\.install4j,* 22.01.2020 10:07:44, ,uuid
files.log,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:40,log
i4jparams.conf,.install4j,Textdateien sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:10:24,conf
i4jruntime.jar,.install4j,Binärdateien sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:10:24,jar
inst_jre.cfg,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:24,cfg
install.prop,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:40,prop
installation.log,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:40,log
installer.ico,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:24,ico
pref_jre.cfg,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:24,cfg
response.varfile,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:40,varfile
stats.properties,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:24,properties
user.jar,.install4j,Nur Rechts: C:\inst\.install4j, ,* 19.01.2020 01:10:24,jar
jre,,Ordner sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:10:23,
bin,jre,Ordner sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:10:19,
concrt140.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
decora_sse.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
fxplugins.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
glass.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
glib-lite.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
gstreamer-lite.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
javafx_font.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
javafx_iio.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
jfxmedia.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
jfxwebkit.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
prism_common.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
prism_d3d.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
prism_sw.dll,jre\bin,Nur Links: c:\zip\jre\bin,* 22.01.2020 10:07:44, ,dll
legal,jre,Ordner sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:10:22,
javafx.base,jre\legal,Nur Links: c:\zip\jre\legal,* 22.01.2020 10:07:44, ,
javafx.controls,jre\legal,Nur Links: c:\zip\jre\legal,* 22.01.2020 10:07:44, ,
javafx.fxml,jre\legal,Nur Links: c:\zip\jre\legal,* 22.01.2020 10:07:44, ,
javafx.graphics,jre\legal,Nur Links: c:\zip\jre\legal,* 22.01.2020 10:07:44, ,
javafx.media,jre\legal,Nur Links: c:\zip\jre\legal,* 22.01.2020 10:07:44, ,
javafx.swing,jre\legal,Nur Links: c:\zip\jre\legal,* 22.01.2020 10:07:44, ,
javafx.web,jre\legal,Nur Links: c:\zip\jre\legal,* 22.01.2020 10:07:44, ,
lib,jre,Ordner sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:10:23,
javafx-swt.jar,jre\lib,Nur Links: c:\zip\jre\lib,* 22.01.2020 10:07:44, ,jar
javafx.properties,jre\lib,Nur Links: c:\zip\jre\lib,* 22.01.2020 10:07:44, ,properties
modules,jre\lib,Dateien sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:09:29,
release,jre,Textdateien sind unterschiedlich,* 22.01.2020 10:07:44, 19.01.2020 01:09:30,
uninstall.exe,,Nur Rechts: C:\inst, ,* 22.01.2020 11:07:44,exe
Benötigst Du zu diesen Dateien weitere Angaben?
Linux i586 dann ein ander Mal. Hunger.
MediathekView_linux_13_6_0-SNAPSHOT_x86.deb MD5: 2ada02efe193af4d56e43e0dc71b018c
rubikon@debiani586:/opt/MediathekView$ jre/bin/java -Xmx1G -jar MediathekView.jar . Portable Mode: false Exception in thread "main" java.lang.NoClassDefFoundError: javafx/collections/ObservableList
edit: auch nach apt-get install openjfx
MV unter Debian i586 läuft nun. War nach dem Installieren von MV relativ einfach.
O.M.G. (und ich sage das als Atheist!) -- ich will das nicht im Forum supporten.
Könnte man nicht einfach sagen, "es ist völlig unmöglich, MV auf Linux i586 zu betreiben" und die echten Linux-Nutzer freuen sich, wenn sie es trotzdem schaffen?
So, und wer hat jetzt einen Snapshot von der VM gemacht, damit ich das Vorgehen reproduzieren kann? Uff. Ohne vmware-tools. Vielen Dank auch...
edit: reproduziert.
@Nicklas2751 wie ist denn Deine Einschätzung zu dem branch feature/32bit? Kannst Du Dir vorstellen, die Änderungen an der pom.xml (geringerer boilerplate, 32-bit Profile) in den develop-branch zu mergen?
Hintergrund meiner Frage: Vielleicht hast Du gesehen, dass ich inzwischen meinen inoffiziellen 13.5.1 Build auf Grundlage Deiner 32-bit pom.xml neu gebaut habe. (Nachdem ich gesehen habe, dass Liberica 13 sogar 32-Bit Windows 7 ins Boot holt)
Für ein etwaiges weiteres Übersetzen von MV 13.5+ für 32-Bit OS und Bauen der MV.jar taugt Deine Änderung m.E. gut. (Was halt die Einschätzung eines Maven-Rookie so wert ist...)
Die von Dir vorab erstellten Installer haken ja etwas -s.o.- Ist für Dich -eingedenk des Marktanteils von 32-Bit Windows + Linux- der 32-Bit Versuch damit insgesamt beendet? Oder wärst Du offen dafür, die Änderungen an der pom.xml (32-bit Profile) separat von install4j-spezifischen Änderungen in den Code fließen zu lassen?
Wenn ich den MV Client für meine 32-Bit Maschine baue kann ich die pom.xml aber genausogut auch selbst zusammenmischen aus dem jeweiligen branch und dem feature/32bit. Danke für die darin enthaltenen Tipps zu Maven!
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
1) use a property for groupId of each JavaFX dependency rather than repeating the text org.jfx for each dependency element
2) add a tag
<type>
to each JavaFX dependency3) 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.