Maven build ermöglichen und automatisieren

[tobidope]

Mit diesem PR wird der build von JVerein von ant auf Maven umgestellt.

Um den Build mit Maven durchzuführen, sind folgende Schritte notwendig:

1. mvn -f setup-build.xml initialize ausführen
   In diesem Schritt werden die Quelltexte von Jameica und Hibiscus aus GitHub heruntergeladen, entpackt und gebaut. Die für JVerein benötigten Bibliotheken aus Jameica, Hibiscus und JVerein werden anschließend in das lokale Maven-Repository installiert und stehen damit im eigentlichen Build zur Verfügung. Außerdem wird die Abhängigkeit zu NumericalChameleon von Sourceforge gezogen und verfügbar gemacht.

2. mvn clean package ausführen
   Im Maven-Build werden die Abhängigkeiten nicht mehr aus den lib Ordnern bezogen, sondern ausschließlich aus dem lokalen oder dem zentralen Maven-Repository. Das Ergebnis ist eine Plugin-ZIP, die analog zum früheren Ant-Build erstellt wird. Sourcen, Tests und Ressourcen sind noch an alter Stelle. Es wäre allerdings sinnvoll nach einem Umstieg auf den Maven Standard umzustellen.

Der größte Vorteil besteht für mich darin, dass neue Entwickler:innen, die an JVerein mitarbeiten möchten, weniger manuelle Schritte durchführen müssen und mit einem zeitgemäßen Build-Tool arbeiten können. Dinge wie das Encoding oder die JDK-Version werden automatisch geprüft. In Zukunft könnten wir weitere Maven-Plugins verwenden, um den Entwicklungsprozess weiter zu vereinfachen.

Der ganze build Prozess wird wesentlich vereinfacht und enthält keine dynamischen Abhängigkeiten. Ein neues Release von Hibiscus oder Jameica führt nicht dazu, dass alte Versionen auf einmal nicht mehr bauen. Zudem ist der build schneller, da das caching nur noch die benötigten Abhängigkeiten nutzt. Der Cache schrumpft von 200 MB auf 90 MB.

Bitte testet den Ablauf und gebt eine Rückmeldung, ob dieser PR gemergt werden kann. Die Anbindung an GitHub Actions bringe ich gerade zuende.

[tolot27]

Geht der maven build ohne Änderung der Verzeichnisstruktur? Das würde den PR deutlich übersichtlicher machen. Es ist ohnehin ein Refactoring geplant. Das wollen wir jedoch schrittweise angehen.

[tobidope]

Kann ich probieren. Macht den build initial komplex, da in src/ Code und Ressourcen liegen. Das würde dann erstmal ein bisschen zaubern müssen.

[tolot27]

Kannst du die file permission changes (100755 → 100644) bitte in einen separaten PR auslagern? Ich halte sie schon für sinnvoll und wir sollten sie unabhängig von diesem PR mergen. Ich hatte schon geschaut, ob es dafür einen Commit gibt. Leider konnte ich keinen identifizieren, zumindest nicht anhand der commit message.

Dann sind auch noch ein paar Dateien geändert, die glaub ich nichts mit maven zu tun haben (z. B. MitgliedLastschriftAction.java). Ich nehme an, dass du da EOL von Windows zu Unix geändert hast, oder?
Bitte das auch in einen separaten Commit packen und gern auch in vorgenannten PR auslagern.

[tobidope]

Diese Anpassungen sind ungewollt passiert, weil ich unter Windows mit Intellij und vermutlich mit einer unpassenden gitconfig arbeite. Ich schaue mal, ob ich es entfernen kann.

[tobidope]

So besser?

[tolot27]

Könntest du bitte in der PR-Beschreibung (erster Kommentar) noch ergänzen, wie die Verzeichnisstruktur dann aussieht und was sich am GitHub Actions Workflow ändert (z. B. Caching)?

Ich sehe als Hauptvorteil von Maven, dass wir die Libs aus dem Git Repository entfernen können. Die liegen dann nur noch im local repository. Allerdings entfernt dieser PR sie noch nicht. Das könntest du noch ergänzen.

Oder ist erstmal gedacht, maven nur side-by-side zu verwenden? Dann dürfte der GitHub Actions Workflow jedoch nicht so stark abgeändert werden. Wie ist hier die Intention?

[tolot27]

Hier bestimmen wir die aktuellen release tags dynamisch. In der POM hast du sie hart kodiert. Kann man das auch dynamisieren? Sonst verlieren wir wieder Flexibilität.

[tobidope]

Das macht den build aber nicht wiederholbar, da er vom Zustand externer Quellen abhängt. Ich würde vorschlagen renovate einzubauen und sehr bewusst die genutzte Version zu aktualisieren.

[tolot27]

Das müsste auch irgendwie dynamisiert werden. Wir sind ja gerade bei 2.9.0-nightly

[tobidope]

Gibt das maven-release-plugin dafür. Habe ich noch nicht eingebaut. Wie wird jetzt hochgezählt?

[tolot27]

Ich glaub diese Versionen lassen sich auch zentraler konfigurieren. Zumindest geht das bei Gradle.

[tobidope]

Ja, ich würde aber vorschlagen renovate einzubauen. Das stellt einem automatisch prs mit neuen Versionen zu den plugins.

[tolot27]

Diese Dateien würde ich noch nicht gleich ignorieren. Nicht jeder wird sofort Maven verwenden.

[tobidope]

Dies sind bereits drin, aber ich kann es gerne wieder rausschmeißen. Mit Maven Projekten ist aber eher schlechter Stil den .classpath im workspace drin zu lassen, da man dann zwei Wahrheiten hat.

[tobidope]

Mit Maven und dem m2e plugin kann man sie eigentlich nicht miteinchecken.

[tobidope]

Könntest du bitte in der PR-Beschreibung (erster Kommentar) noch ergänzen, wie die Verzeichnisstruktur dann aussieht und was sich am GitHub Actions Workflow ändert (z. B. Caching)?

Werde ich noch ergänzen.

Ich sehe als Hauptvorteil von Maven, dass wir die Libs aus dem Git Repository entfernen können. Die liegen dann nur noch im local repository. Allerdings entfernt dieser PR sie noch nicht. Das könntest du noch ergänzen.

Oder ist erstmal gedacht, maven nur side-by-side zu verwenden? Dann dürfte der GitHub Actions Workflow jedoch nicht so stark abgeändert werden. Wie ist hier die Intention?

Ich würde es komplett ändern wollen, würde mir aber wünschen, dass es jemand mal lokal bei sich ausprobiert. Dann würde ich die libs rausschmeißen. Alle können nicht raus, da z.B. nc.jar nicht via Maven herunterladbar ist und diese Version nicht im Internet existier.

[dippeal]

Dann funktioniert aber die "AboutView" Ausgabe der Version wie in #325 angepasst und damals gefordert nicht mehr.

[tobidope]

Wenn man es mit maven package baut, wird mit dem ressource plugin die plugin.xml gefiltert und enthält dann im jverein-<version>.zip die korrekte Version. In Maven wird man die Version nur einer Stelle pflegen, in der pom.xml. Alles andere wird beim build erzeugt und nutzt die Daten der pom.xml. So wird sichergestellt, dass es keine Inkonsistenzen gibt. Aber das Starten aus dem workspace passt dann nicht, man müsste das plugin.zip entpacken und als plugin verzeichnis für jameica nutzen. Es separat zu verwalten, fände ich schwierig. Du kannst in meinem repo mal ein release anschauen https://github.com/tobidope/jverein/releases/tag/2.9.0-SNAPSHOT. Dort müsste alles passen.

[tobidope]

Es wäre eine Option ein profil lokal zu aktivieren z.B. local-test, dass die plugin.xml für den Test generiert. Die Basis dafür wäre ein plugin.xml aus den src/main/resources.

[tobidope]

Soll ich hier weitermachen, oder ist eine Aufnahme eher unwahrscheinlich?