WoPeD nach Installation starten

[nileger]

delay hinzufügen

[ChelloX]

Ist in Bearbeitung.
Das Problem ist aktuell, dass WoPeD - wenn aus IzPack gestartet - den Install-Prozess blockiert und der Install-Wizard bis zum Schließen WoPeDs im Hintergrund weiterläuft.
Mehrere Lösungen denkbar:

1. Die Blockade hinnehmen -> nicht schön aber auch nicht schlimm. Bisher keine Beeinträchtigung der Funktionalitäten festgestellt.
2. WoPeD nicht mehr automatisch aus dem Install-Wizard starten -> einfachste Lösung
3. Implementierung eines eigenen FinishPanel für IzPack, welches WoPeD zum Ende des Install-Wizards startet und überschreiben des Default-FinishPanel -> genau genommen wird der InstallWizard weiterhin blockiert, es sollte so jedoch möglich sein WoPeD mit dem Schließen der Wizard-GUI zu starten. So fällt die Blockade (zumindest auf GUI-Ebene) nicht mehr auf.

[tfreytag]

Habe den Windows Installer aus dem master gebildet und dann auf Windows 10 ausgeführt. Läuft durch, aber der Auto-Start klappt nicht, ist das jetzt beabsichtigt? Weiß leider nicht mehr, was der Stand unserer Besprechung letzte Woche war...
Ansonsten schaut es ganz gut aus mit der Funktionalität unter Windows und MacOS. Will aber nächste Woche noch weitere Tests machen, auch für Linux.

Habe auch mal versucht, das ant-Skript zum Bauen des MacOS-Installers in die pom.xml im WoPeD-Installer zu integrieren, geht wohl mit einem Plugin. Habe das wie im Howto beschrieben eingefügt und den Inhalt des Ant-Skripts aus dem Ordner "mac" dort leicht angepasst eingefügt. Leider gibt es eine Fehlermeldung. Vielleicht weiß jemand von euch, woran es liegt, die Debug-Info ist leider nicht sehr aussagekräftig:

Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (step6) on project WoPeD-Installer: An Ant BuildException has occured: java.lang.IllegalStateException: Icon does not exist.

Von mir angepasste pom-datei anbei.

pom.xml.zip

[tfreytag]

Es scheint wohl beim Ausführen des tasks "bundleapp" zu passieren (aus externer Jar), mit der die ausführbare Struktur WoPeD.app gebaut wird. Direkt unter ant klappt das alles wunderbar.

[ChelloX]

Auf die Schnelle schaut es so aus, als ob er den Pfad zu dem Icon nicht finden kann.
"Icon does not exist."
Wenn ich zuhause bin kann ich mehr dazu sagen.

Dass er nicht mehr automatisch startet nach der Installation ist erstmal so gewollt.

[tfreytag]

Habe den Fehler gefunden, war tatsächlich der Pfad zum Icon. Jetzt wird der Mac-Installer von maven im Module WoPeD-Installer immer mit gebildet. Müsste wohl nur noch in die Deployment Pipeline eingefügt werden, oder? Derzeit landet die Datei (*.pkg) einfach im Ordner target/MacOS. Habe übrigens die Installer-Dateien einheitlich umbenannt in WoPeD-install--.[jar | exe | pkg].

[nileger]

Vorab hier eine kurze Klarstellung zu den Begrifflichkeiten:
Eigentlich sprechen wir hier nicht von einer Deployment-Pipeline denn es wird ja keine Anwendung deployt. Auch die Pipelines für die beiden Webservices sehen aktuell kein automatisches Deployment vor (das hatten wir damals so besprochen). Vielmehr geht es hier um die Build-Pipeline.

Wir bzw. ich muss dann noch die Build-Pipeline anpassen (da sich jetzt die Namen und Pfade der erzeugten Dateien geändert haben) damit die Installer auf den Nexus hochgeladen werden. Den MacOS-Installer muss man m. W. nach wie vor lokal bauen, da das ja nur unter MacOS geht. Der Server, auf dem Jenkins läuft, ist allerdings ein Linux-Server und kann deshalb den MacOS-Installer nicht bauen.

[tfreytag]

Das Anpassen der Build-Pipeline meinte ich ja auch, vor allem bzgl. einheitliche Namen der Artefakte.

Es sollte doch eine Möglichkeit geben, die Regel für den Mac-Installer nur auszuführen, wenn es unter dem Betriebssystem MacOS ausgeführt wird: https://stackoverflow.com/questions/27941091/maven-how-to-allow-a-certain-os-for-build

Vielleicht weiß ja jemand von euch, wie man mit diesem Plugin den "step6" im pom.xml plattformabhängig machen kann?

[nileger]

Ich habe die Pfade zu den neu benannten Installern angepasst. Die beiden Installer werden jetzt korrekt von Jenkins in unser Nexus Repository gepusht. Um automatische Builds (und dadurch auch automatische Mails an Entwickler, die einen kaputten Build verursachen) zu ermöglichen benötigen wir GitHub WebHooks. Hierzu habe ich eine Mail an die IT-Abteilung der DH geschrieben.

[nileger]

M. E. ist es nicht notwendig, das Erstellen des Mac-Installers unter nicht-MacOS zu unterbinden. Der Build läuft dadurch nicht erheblich schneller durch und Fehler treten unter Windows/Linux auch nicht auf.