Maven build ermöglichen und automatisieren #614

tobidope · 2025-01-27T20:38:59Z

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

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

mvn -f setup-build.xml clean install 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.
mvn clean verify 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. Das plugin.zip ist im target Verzeichnis entpackt unter dem Ordner target/jverein. Dieses Verzeichnis kann als plugin in Jameica eingebunden werden.

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 · 2025-01-27T21:39:44Z

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 · 2025-01-27T22:40:32Z

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 · 2025-01-28T12:00:49Z

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 · 2025-01-28T12:13:01Z

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 · 2025-01-28T20:19:33Z

.github/workflows/reusable-build.yml

-        jameica_tag=$(git ls-remote --refs --tags --sort="-v:refname" https://github.com/willuhn/jameica.git V_\* | head -1 | cut -f 2 | cut -d / -f 3)
-        echo "jameica_tag=${jameica_tag}" >> $GITHUB_ENV
-        hibiscus_tag=$(git ls-remote --refs --tags --sort="-v:refname" https://github.com/willuhn/hibiscus.git V_\* | head -1 | cut -f 2 | cut -d / -f 3)


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.

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.

Das macht den build aber nicht wiederholbar, da er vom Zustand externer Quellen abhängt.

Da hast du Recht. Das ist jedoch für die nightly builds absolut relevant. Nicht, dass wir von den Quellen abhängig wären. Wir bräuchten die Libs von Jameica und Hibiscus. Wenn die in einem maven repository lägen, wäre das ideal. Da könnten zumindest die Releases liegen. Ich hatte auch schon versucht, über Repology die aktuelle Version zu bekommen. Da habe ich jedoch die Rest-API nicht richtig nutzen können. In #516 (comment) hatte ich zumindest mal das Fetching der Jars mit remotezip dokumentiert. Vielleicht ist das für diesen PR eine Möglichkeit? Zumindest braucht es für unsere Releases kein compile der nightlies von Jameica und Hibiscus. Das wäre nur für unser future-proof notwendig.

Ich würde vorschlagen renovate einzubauen.

Meinst du https://github.com/renovatebot/renovate?

Ich meine genau das renovate. Das hat github-tags als data source. D.h. man kann es konfigurieren, automatisch einen pull reuqest zu stellen, wenn Jameica oder Hibiscus ein neue Version bereitstellen. Die baut dann natürlich auch und du siehst sofort, ob es noch baut.

Ich habe übrigens auch schon mal getestet, die benötigten jars in das GitHub maven repository zu installieren, das funktioniert auch, und würde den tatsächlichen build step völlig unabhängig vom reusable-Build machen. Zum lokalen Test braucht man immer noch die Plugin.zip entpackt und es ist wirklich nett, direkt in den source von Jamaica zu schauen.

pom.xml

tolot27 · 2025-01-28T20:21:59Z

pom.xml

+
+    <groupId>io.github.openjverein</groupId>
+    <artifactId>jverein</artifactId>
+    <version>2.8.24-SNAPSHOT</version>


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

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

tolot27 · 2025-01-28T20:24:24Z

setup-build.xml

+            <plugin>
+                <groupId>org.apache.maven.plugins</groupId>
+                <artifactId>maven-install-plugin</artifactId>
+                <version>3.1.3</version>


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

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

setup-build.xml

tolot27 · 2025-01-28T20:28:20Z

.gitignore

+# Eclipse Core
+.project
+# JDT-specific (Eclipse Java Development Tools)
+.classpath


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

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.

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

Und warum müssen die IDEA-Verzeichnisse/Dateien so detailliert exkludiert werden? Reicht da nicht einfach auch das .idea/ was schon drin ist?
Das gilt natürlich eigentlich auch für die Eclipse prefs. 😏

.github/workflows/reusable-build.yml

tobidope · 2025-01-28T21:51:50Z

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 · 2025-01-30T10:05:17Z

plugin.xml

@@ -1,7 +1,7 @@
 <plugin xmlns="https://www.willuhn.de/schema/jameica-plugin"
        xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="https://www.willuhn.de/schema/jameica-plugin https://www.willuhn.de/schema/jameica-plugin-1.5.xsd"
-        name="jverein" version="2.9.0" class="de.jost_net.JVerein.JVereinPlugin">
+        name="jverein" version="${project.version}" class="de.jost_net.JVerein.JVereinPlugin">


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

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.

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.

Aber das Starten aus dem workspace passt dann nicht, man müsste das plugin.zip entpacken und als plugin verzeichnis für jameica nutzen.

Kann man nicht ein inject über die run configuration machen?

Ich habe eingebaut, dass mvn verify das plugin.zip im Verzeichnis target entpackt. Wenn dies als plugin quelle genutzt wird, funktioniert alles so wie es soll. Ich muss die Doku vom PR und CONTRIBUTING.md noch anpassen.

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

Ich glaube @dippeal meinte, dass man dann kein live debugging und live code changes mehr machen kann, wenn das Plugin nicht mehr vom source Verzeichnis geladen werden kann (wegen fehlender Version), wie es unter Wie richte ich mir das Beispiel-Plugin in Eclipse ein? beschrieben ist.

Das Problem war, dass die Plugin Version nicht geparst werden konnte und beim starten aus der IDE immer ein Exception kam. Außerdem sind abhängige Plugins dann nicht geladen. Siehe #324

Das Problem gibt es nicht. Man nutzt einfach die Version im Target Ordner. Bei Änderungen muss ein mvn verify durchgeführt werden, damit der Test funktioniert.

Die Exception kommt mit diesem PR auch nicht.

tobidope · 2025-01-31T17:16:30Z

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

tolot27 · 2025-02-02T21:24:45Z

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

Ich glaub vor dem 3.0er Release kommt es nicht rein. Danach kann ich mir das vorstellen. Dann haben wir alle genug Zeit zum Testen und dran gewöhnen. Ich werde es demnächst lokal ausprobieren.

tolot27 · 2025-02-02T21:51:37Z

Kannst du bitte das force-push immer nur dann machen, wenn es wirklich notwendig ist? Solange wie es niemand ausgechecked hat, ist es noch unproblematisch. Das wird jedoch irgendwann zum Problem.

tobidope · 2025-02-02T21:55:33Z

Ich versuche immer nah am master branch zu bleiben. Solange keiner mit mir am branch arbeiten wollte, sollte es unproblematisch sein. Wenn man länger nicht rebased kann das ganz schön fummelig sein. Ist mir diese Woche passiert.

Damit kann der lokale Test durch Einbinden von target/jverein als plugin in Jameica durchgeführt werden

tobidope · 2025-02-16T14:23:43Z

Ich mache das erstmal zu. Ich fange kleiner an. Erstmal den ant build sinnvoll verbessern und wenn das alles läuft. Können wir vielleicht auf Maven oder Gradle wechseln.

tolot27 · 2025-02-16T15:25:45Z

Ich mache das erstmal zu. Ich fange kleiner an. Erstmal den ant build sinnvoll verbessern und wenn das alles läuft. Können wir vielleicht auf Maven oder Gradle wechseln.

Oh, dass finde ich jetzt überraschend. Ich hätte es begrüßt, wenn wir auf Maven (oder Gradle) gewechselt wären.

tobidope · 2025-02-16T16:15:11Z

Ich hatte das Gefühl, das ist zu groß um in endlicher Zeit gemerged zu werden. Den Branch habe ich noch.

tolot27 · 2025-02-16T16:58:27Z

Wir hatten schon einige PRs, die eine Reviewzeit von mehreren Monaten hatten. Ich halte den PR für ziemlich wichtig. Daher öffne ich ihn wieder.

tobidope requested review from mbmueller and NicoB77 January 27, 2025 20:39

tobidope force-pushed the feature/mavenBuild branch from d83dc52 to cbc0a17 Compare January 27, 2025 23:58

tolot27 requested changes Jan 28, 2025

View reviewed changes

tobidope mentioned this pull request Jan 28, 2025

Update Docu Link zu v3.0.x #616

Merged

tobidope requested a review from tolot27 January 28, 2025 13:53

tobidope force-pushed the feature/mavenBuild branch from 8647850 to 41fa2b5 Compare January 28, 2025 17:01

tolot27 requested changes Jan 28, 2025

View reviewed changes

tobidope force-pushed the feature/mavenBuild branch from 740979c to adb2834 Compare January 28, 2025 21:42

tobidope force-pushed the feature/mavenBuild branch from 1b17de5 to de9c8bc Compare January 29, 2025 18:09

tobidope requested a review from tolot27 January 29, 2025 18:15

dippeal reviewed Jan 30, 2025

View reviewed changes

tobidope requested a review from dippeal January 30, 2025 19:21

tobidope force-pushed the feature/mavenBuild branch from 7f7815b to 0d2421e Compare January 31, 2025 21:06

tobidope added the help wanted Extra attention is needed label Feb 1, 2025

tobidope force-pushed the feature/mavenBuild branch 2 times, most recently from 4088907 to 0cb1d62 Compare February 2, 2025 15:02

tobidope force-pushed the feature/mavenBuild branch from 9ec2b4e to 3ff6449 Compare February 2, 2025 21:34

tobidope force-pushed the feature/mavenBuild branch 3 times, most recently from afdf882 to 04f2311 Compare February 4, 2025 21:31

tobidope added 22 commits February 11, 2025 17:21

Eindeutige ids in github actions

a72f299

Rebase fixen

6003c26

Entpacken der plugin.zip ins target an verify gebunden

aa1ab8b

Damit kann der lokale Test durch Einbinden von target/jverein als plugin in Jameica durchgeführt werden

Run config für Idea eingecheckt

a492c6d

IDEA Projektfile automatisch bereitstellen

0ca0bf8

reusable-build.yml auf neuen maven lifecycle angepasst

df3bfa8

jameica Projekt angepasst

d11657e

Eclipse auf Maven umgestellt

f1db21d

Maven wrapper hinzugefügt, damit ein lokales maven nicht notwendig ist

869b492

Build auf maven wrapper umgestellt

d1d515c

jameica.iml automatisch auf build der aktuellen version zeigen lassen

d6ce8c1

buildcheck immer laufen lassen und mvnw executable bit gesetzt

29fd1b8

Eclipse Launcher einbinden

c3d024f

Leerzeile am Ende eingebunden

255b1c5

Zwischenstand: Dokumentation angepasst

463648d

Dokumentation erweitert

01c9450

Java 11 Verwendung angepasst

d97f860

Java 11 Verwendung angepasst

8102234

Auf compiler release umgestellt

a5f02e1

Unnötiges property entfernt

e788529

Neue Hibiscus Version eingebunden

293b954

Version auf upstream angepasst

cb941c3

tobidope force-pushed the feature/mavenBuild branch from 03ff6b3 to cb941c3 Compare February 12, 2025 16:32

Auf neue jameica version angepasst

0df89ee

tobidope closed this Feb 16, 2025

tolot27 reopened this Feb 16, 2025

Maven build ermöglichen und automatisieren #614

Are you sure you want to change the base?

Maven build ermöglichen und automatisieren #614

Conversation

tobidope commented Jan 27, 2025 • edited Loading

tolot27 commented Jan 27, 2025

tobidope commented Jan 27, 2025

tolot27 left a comment

Choose a reason for hiding this comment

tobidope commented Jan 28, 2025

tobidope commented Jan 28, 2025

tolot27 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobidope commented Jan 28, 2025

Choose a reason for hiding this comment

tobidope Jan 30, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobidope Feb 9, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobidope commented Jan 31, 2025

tolot27 commented Feb 2, 2025

tolot27 commented Feb 2, 2025

tobidope commented Feb 2, 2025

tobidope commented Feb 16, 2025

tolot27 commented Feb 16, 2025

tobidope commented Feb 16, 2025

tolot27 commented Feb 16, 2025

tobidope commented Jan 27, 2025 •

edited

Loading

tobidope Jan 30, 2025 •

edited

Loading

tobidope Feb 9, 2025 •

edited

Loading