Aktuelles Nighly läuft nicht

[MenchenSued]

@DerReisende77 sagte in Aktuelles Nighly läuft nicht:

welches OS und welches JDK?

Nur der Vollständigkeit halber, JDK:

IMPLEMENTOR="Eclipse Adoptium"
IMPLEMENTOR_VERSION="Temurin-23.0.2+7"
JAVA_RUNTIME_VERSION="23.0.2+7"
JAVA_VERSION="23.0.2"
JAVA_VERSION_DATE="2025-01-21"
LIBC="gnu"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets jdk.internal.opt jdk.zipfs jdk.compiler jdk.crypto.cryptoki jdk.crypto.ec jdk.dynalink jdk.internal.ed jdk.editpad jdk.internal.vm.ci jdk.graal.compiler jdk.graal.compiler.management jdk.hotspot.agent jdk.httpserver jdk.incubator.vector jdk.internal.le jdk.internal.md jdk.jartool jdk.javadoc jdk.jcmd jdk.management jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.nio.mapmode jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported jdk.unsupported.desktop jdk.xml.dom"
OS_ARCH="x86_64"
OS_NAME="Linux"
SOURCE=".:git:ff87e76b386d"
BUILD_SOURCE="git:aaf9cbd0641cf21daa951c69ef6d7183b3af9e99"
BUILD_SOURCE_REPO="https://github.com/adoptium/temurin-build.git"
SOURCE_REPO="https://github.com/adoptium/jdk23u.git"
FULL_VERSION="23.0.2+7"
SEMANTIC_VERSION="23.0.2+7"
BUILD_INFO="OS: Linux Version: 6.8.0-1018-azure"
JVM_VARIANT="Hotspot"
JVM_VERSION="23.0.2+7"
IMAGE_TYPE="JDK"

unter Linux MINT 21.3

[DerReisende77]

Interessanterweise startet es problemlos aus der IDE hängt aber mit denselben Parametern auf der CLI. Bin noch am debuggen.

[DerReisende77]

Es liegt an der Art&Weise wie das jar erstellt wird Das wird eine Weile dauern bis ich das debugged habe.

[DerReisende77]

@Cloud9 Baust Du MV selbst via git? Habe für macOS Apple Silicon einen Lösung die bei mir läuft. Ein Test abseits davon wäre aber super

[Cloud9]

@DerReisende77 Ja, nach der hervoragenden Anleitung von styroll.

[DerReisende77]

@Cloud9 Super! Mach mal bitte folgendes:

git pull
git switch fix-startup-macos-apple-silicon
mvn clean install
cd target
java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:+UseStringDeduplication -XX:MaxRAMPercentage=50.0 \
--enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.vector --add-exports=java.desktop/sun.swing=ALL-UNNAMED \
-ea -cp "MediathekView.jar:dependency/*" mediathek.Main

Damit sollte MV wieder starten ohne Fehler.
Rückmeldung wäre nett

[DerReisende77]

@MenchenSued Wenn Du auch selbst baust, würde folgendes für dich gelten:

git pull
git switch fix-startup-macos-apple-silicon
mvn clean install
cd target
java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:+UseStringDeduplication -XX:MaxRAMPercentage=50.0 \
--enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.vector --add-exports=java.desktop/sun.swing=ALL-UNNAMED \
--add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -ea -cp "MediathekView.jar:dependency/*" mediathek.Main

auch wenn der branch fix-startup-macos-apple-silicon heisst habe ich dort gerade auch den linux x86 fix eingebaut.

[Cloud9]

@DerReisende77 ist das was unterhalb von cd target steht eine Zeile?
Ich erhalte hier nach reinkopieren davon die Fehlermeldung: ```
zsh: command not found: ava

[Cloud9]

Bin blind. Hatte das j von java nicht mitkopiert. Läuft zur Zufriedenheit!

[DerReisende77]

keine Fehler mehr?

[Cloud9]

@DerReisende77 Keine.

[DerReisende77]

Gut Wenn @MenchenSued noch ein Feedback gibt kann ich auch die binaries entsprechend umbauen.

Interessanterweise scheint der Fehler unter Windows nicht aufzutreten.

[Cloud9]

Das sogar Fehler da nicht auftreten mögen wundert mich nicht wirklich

[DerReisende77]

So ich habe gerade die Änderungen für den Bau der Binaries für Linux und Windows nach develop gepushed. Ich hoffe ich war früh genug dran damit die nightlies ab morgen wieder funktionieren. Für eine Rückmeldung wäre ich dankbar.

[DerReisende77]

@Cloud9 Die macOS Änderungen sind nun auch in develop drin. Die Startparameter bleiben ab sofort wie oben beschrieben.

[MenchenSued]

@DerReisende77
Ja, unter Linux startet MV jetzt auch wieder korrekt. Allerdings werden mir im Filterpanel alle Sender angezeigt, auch die, die ich gar nicht lade. Aber das ist ein anderes Thema und muss nicht hier diskutiert werden. Ihr bastelt ja gerade an vielen Stellen und die Feinjustierung kommt sicherlich noch.

[Cloud9]

@MenchenSued hattest du deine nightly Version auch als quasi portable Ausführung installiert?
Hab heute morgen erst gesehen, dass mit dem neuen Startbefehl gestartet nicht mehr auf die Daten unter ~/Applications/MediathekView_Nightly/Einstellungen/.mediathek3 zugegriffen wird, sondern auf die der (von mir gleichfalls aktuell gehaltenen und jetzt um Chaos zu verhindern entfernten) Normalen alten Version unter ~/.mediathek3 bzw. im Fall der filme.json auf ~/Library/Caches/MediathekView/filme.json.

[MenchenSued]

Mein Startskript sieht wie folgt aus und nutzt ein lokales Verzeichnis, das ich als letzten Parameter anhänge

#!/usr/bin/sh
cd target
../../jdk-23.0.2+7/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:+UseStringDeduplication -XX:MaxRAMPercentage=50.0 \
--enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.vector --add-exports=java.desktop/sun.swing=ALL-UNNAMED \
--add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -ea -cp "MediathekView.jar:dependency/*" mediathek.Main ../mediathek3

[Cloud9]

@MenchenSued das ähnelt meinem derzeitigen

#!/bin/sh
cd ~/MediathekView/target
java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:+UseStringDeduplication -XX:MaxRAMPercentage=50.0 \
--enable-native-access=ALL-UNNAMED --add-modules jdk.incubator.vector --add-exports=java.desktop/sun.swing=ALL-UNNAMED \
--add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -ea -cp "MediathekView.jar:dependency/*" mediathek.Main

Das vorherige war deutlich anders nämlich so

#!/bin/sh
dir=`dirname "$0"`
cd "$dir"
JAVA_HOME="/Library/Java/JavaVirtualMachines/zulu-22.jdk/Contents/Home"
if [ -n "$JAVA_HOME" ]; then
"$JAVA_HOME"/bin/java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:MaxRAMPercentage=50.0 -XX:
+UseStringDeduplication --add-exports javafx.base/com.sun.javafx.event=ALL-UNNAMED --add-exports
javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED --add-exports
javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED --add-exports
javafx.graphics/com.sun.javafx.scene.traversal=ALL-UNNAMED -Dfile.encoding=UTF-8 -jar
~/Applications/MediathekView_Nightly/MediathekView\-latest\-nightly\-mac/MediathekView\.jar
~/Applications/MediathekView_Nightly/Einstellungen/.mediathek3 $*
else
java -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=compact -XX:MaxRAMPercentage=50.0 -XX:
+UseStringDeduplication --add-exports javafx.base/com.sun.javafx.event=ALL-UNNAMED --add-exports
javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED --add-exports
javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED --add-exports
javafx.graphics/com.sun.javafx.scene.traversal=ALL-UNNAMED -Dfile.encoding=UTF-8 -jar ./MediathekView.jar
~/Applications/MediathekView_Nightly/Einstellungen/.mediathek3 $*
fi
cd $OLDPWD
killall Terminal

Das neue funktioniert aber und daher lass ichs jetzt wie es ist. Die vorherige Situation mit zwei parallelen Instanzen hatte ich als Notnagel gedacht, aber eigentlich nur noch die nightly Version aktiv genutzt.