JavaLand 2026 Rückblick: Drei praktische Maven-Ideen, die du sofort ausprobieren kannst

Probiere mvnd (Maven Daemon) aus, ein Drop-In-Ersatz für mvn. mvnd hält eine JVM im Hintergrund »warm« und behält daher auch etliche Klassen (z.B. von Plugins) im Speicher. Das Haupt-Feature ist aber der parallele Build von mehreren Modulen Deines Reactor-Projektes gleichzeitig.

Falls Du Warnungen siehst, dass einige Plugins nicht threadsafe seien, prüfe zuerst, ob es Updates für diese Plugins gibt. Falls es wider Erwarten keine Updates für die betroffenen Plugins gibt, solltest Du vielleicht ein Issue bei den Plugin-Maintainern öffnen, da diese Plugins thread-safe sein sollten, um mit mvnd oder mvn -T1C zu arbeiten.

Falls alles fehlschlägt, kannst Du versuchen, die Warnungen zu ignorieren — wenn es funktioniert, funktioniert es. Es ist letztlich nur ein Flag, welches aktiv vom Plugin-Maintainer gesetzt werden muss. Ansonsten kannst Du auch auf ein anderes Plugin mit ähnlicher Funktionalität umsteigen, wenn alle Stricke reißen.

Möchtest Du tiefer in die Materie eintauchen, schau Dir gerne meinen Artikel Feed the Daemon: Faster Builds with Maven Reactor Modules an.

Das war DAS Thema: »Füttere den Maven Daemon«: Falls Du einen neuen Service oder eine neue Funktionalität zu Deiner Anwendung hinzufügen möchtest, erstelle ein neues Maven-Modul. Auf diese Weise erstellst Du »Futter« für den Maven Daemon, da die Abhängigkeiten zwischen den Modulen immer weniger und weniger linear werden. Sequentielle Builds können dann in parallel kompilier- und testbare Module aufgebrochen werden - je mehr Module das Projekt hat, desto besser.

Die Apache Maven Build Cache Extension ist eine noch relativ neue Erweiterung, die es Dir erlaubt, Build-Artefakte und Abhängigkeiten Deiner Module zu cachen.

Stell Dir vor, du hast ein Reactor-Projekt mit 5 sequentiellen Modulen, und du änderst etwas in Modul 5. Warum solltest du alles von Modul 1 bis 5 neu bauen, wenn du nur Modul 5 neu bauen musst? Die Build Cache Extension ermöglicht es dir, die Build-Artefakte von Modul 1 bis 4 zu wiederzuverwenden. Verwendest du zusätzlich einen Remote Cache, kannst du sogar einen Build Cache nutzen, der auf einer anderen Maschine erstellt wurde, z.B. in einer CI-Umgebung oder von einem Kollegen.

Bitte teile deine Erfahrungen und Ergebnisse deiner Experimente mit der Apache Maven Build Cache Erweiterung auf der Apache Maven User Mailing Liste.

A: Wir empfehlen Dir nicht, die Architektur Deines Builds nur wegen der Geschwindigkeit des Builds zu ändern. Allerdings bringt Dir diese Änderung nicht nur Vorteile um der Geschwindigkeit Willen, sondern geht meistens auch mit einer besseren Architektur einher. Das hängt aber wirklich im Einzelfall vom Projekt bzw. Build ab.

Falls Du eine kleine Anwendung pflegst, kann das auseinanderreißen in einzelne Module die Arbeit nicht wert sein. Vermutlich dürfte es die Build-Zeit eh nicht wesentlich beeinflussen.

Pflegst du andererseits eine größere Anwendung, dann kann die Modularisierung die Build-Zeit und halt auch die Wartbarkeit deutlich positiv beeinflussen. Durch das auseinandernehmen der Anwendung in kleinere, fokussiertere Module kannst du vermeiden, dass Du in einem Modul Klassen aus einem anderen Modul nutzt, die Du hier nicht nutzen solltest. Legt man für einen einzelnen Service ein eigenes Modul an, führt das auch zum »separation of concerns« (wörtlich: »Trennung der Belange«), und das ist ein Prinzip eines guten Software-Designs.

Der Seiteneffekt ist das, was wir vorgestellt haben: Mehrere Module können parallel gebaut werden.

A: Die Antwort auf diese Frage hängt deutlich vom Reactor-Projekt ab.

Wir waren positiv überrascht, dass niemand aus dem Publikum noch JUnit 4, TestNG or Spock verwendet hat. Wir hatten erwartet, dass zumindest wenige Benutzer noch diese Test-Frameworks nutzen. Aber scheinbar haben schon alle auf JUnit Jupiter migriert. Wow! Bravo!

Falls du mvnd nicht in deiner Continuous Integration-Umgebung nutzen kannst, denken erstaunlich wenige an die Nutzung von Apache Maven Wrapper, und wussten teilweise gar nicht, dass dieser existiert.

Besonders in Projekten, wo Du als Maintainer keine Kontrolle über Notebooks hast, ist ein »blessed« Build wichtig. Hierfür kann man via des Apache Maven Wrappers eine Apache Maven-Version »soft-forcieren«. Auch Entwicklungsumgebungen erkennen und empfehlen die Nutzung des Wrappers. Dieser wird dann üblicherweise auch in der Integrations-Umgebung verwendet, wenn Du deine Workflows oder Jenkinsfiles so konfigurierst, dass sie bash ./mvnw anstatt mvn ausführen.

Der große Vorteil dieses Ansatzes: Alle Entwickler und CI-Umgebungen verwenden die gleiche Version von Apache Maven, was dazu beitragen kann, Build-Probleme zu vermeiden, die durch unterschiedliche Maven-Versionen verursacht werden.

Eine weitere Sache, die uns ein bißchen überrascht hat, war die Tatsache, dass viele Leute das Apache Maven Enforcer Plugin nicht kannten oder zumindest nicht nutzten. Falls Du es nicht kennst kann ich nur empfehlen, es dir mal anzuschauen.

Was es kurz gesagt macht: Beim Start des Builds (in der ersten Phase) führt es eine Reihe von einfachen, in XML definierten Regeln aus um zu prüfen, ob die Build-Umgebung bestimmte Bedingungen erfüllt. Das kann etwa die Mindest-Version von Apache Maven sein, die Java-Version, das Betriebssystem, das Vorhandensein einer bestimmten Datei oder aber auch das Fehlen von bestimmten Abhängigkeiten.

Einige der eingebauten Regeln des maven-enforcer-plugins sind:

Ein paar interessante Mojohaus Extra Enforcer Regeln sind: