Wie ich in Teil 0: Über ‘Boring Technology’ dargelegt habe, gibt es ein paar Eigenschaften, die eine Technologie zu einer ‘Boring Technology’ machen. Ein Paradebeispiel für eine solche Technologie ist - meiner Meinung nach - das Build-Tool Maven.

Zu erklären, was es tut, ist ziemlich einfach. Zu erklären, wie man es benutzt (mvn verify) ist ziemlich einfach (für ~90% der Anwendungsfälle). Es durch ein anderes Build-Tool zu ersetzen ist, abhängig von den Plugins, die man benutzt, nicht trivial, aber im Allgemeinen machbar.

Die Verbreitung in der Industrie ist groß, viele Projekte verwenden Maven als Build-Tool und die meisten Java-Entwickler haben Erfahrung damit. In Anbetracht der Tatsache, dass Maven rund 18 Jahre alt ist und von der Apache Foundation gepflegt wird, kann man, meiner Meinung nach, mit relativ großer Sicherheit sagen, dass es zukunftssicher ist.

Das hier ist kein Tutorial, aber ich möchte ein paar wichtige Eigenschaften hervorheben, die Maven zu einer guten Wahl machen.

Das POM (Project Object Model)

Mit Maven definieren Sie die Abhängigkeiten Ihres Projekts, wie Ihr Projekt im sogenannten Project Object Model gebaut wird, das normalerweise in einer Datei namens pom.xml geschrieben wird. Ja, es ist XML, es sieht klobig aus und hat eine Menge “noise”. Aber ich behaupte, dass das POM die Killerfunktion von Maven ist. Das klingt vielleicht etwas kontrovers und ich werde es gründlich erklären müssen, also hab bitte Geduld mit mir.

Nehmen wir einen Konkurrenten, Gradle, zum Beispiel. In Gradle wird die Build-Definition entweder in Groovy oder Kotlin geschrieben, was es verlockend macht, den Build-Prozess zu sehr zu optimieren. Gradle erlaubt es Ihnen auch, einen beliebig komplexen Graphen von voneinander abhängigen Aufgaben zu erstellen. Im Gegensatz dazu erscheint die Struktur eines Maven-Builds mit seinem vordefinierten Lebenszyklus sehr einschränkend.

In der Praxis ist sie jedoch völlig ausreichend und sorgt dafür, dass alle Maven-Projekte eine sehr ähnliche Struktur haben. Wenn man über den Designraum und die Kompromisse zwischen einer vollwertigen Programmiersprache und einer eingeschränkten Struktur nachdenkt, sollte man sich ansehen, was die ’new kids on the block’ machen: [Cargo.toml von Rust] (https://doc.rust-lang.org/cargo/reference/index.html), cabal-File von Haskell, package.json von NPM. Was haben all diese Build-Tools gemeinsam? Sie haben eine sehr eingeschränkte Struktur.

Mit anderen Worten, Maven ist sehr ‘opioniated’, wenn es darum geht, wie Sie Ihr Projekt strukturieren sollten, was es für andere, die Ihrem Projekt beitreten, einfach macht, sich zurechtzufinden und Ihren Build-Prozess zu verstehen.

Übrigens, wenn es nur die XML-Syntax ist, die Sie stört, gibt es takari/polyglot-maven, das Ihnen erlaubt, Ihr POM in verschiedenen syntaktischen Varianten zu schreiben, z.B. YAML.

So, nachdem wir nun über die Anti-Features gesprochen haben, die Maven nicht hat, können wir auch über die Features sprechen, die Maven hat. Meiner Meinung nach glänzt Maven, wenn Sie mehr als ein Projekt oder Modul haben, die miteinander verbunden sind, da Maven eine Vielzahl von Funktionen hat, um diese zu strukturieren. Werfen wir einen Blick darauf!

(Anmerkung: Wenn Sie nach einem Tutorial suchen, schauen Sie sich Maven in 5 Minutes an, und wenn Sie nach tiefergehenden Informationen suchen, gibt es die umfassende POM reference

Archetypes

Die Archetypen von Maven sind im Grunde Blaupausen für die Erstellung neuer Projekte. Wenn Sie Javascript entwickeln, dann kennen Sie vielleicht Yeoman, das im Grunde die gleiche Idee verfolgt. Es ist auch sehr einfach, neue Vorlagen hinzuzufügen, da es sich dabei um reguläre Maven Artefakte handelt, die Sie zum Beispiel in Maven Central oder Ihre lokale Artifactory hochladen können. Um ein neues Projekt unter Verwendung eines Artefakts (hier: maven-archetype-quickstart) zu erstellen, führen Sie einfach mvn archetype:generate -DarchetypeArtifactId=maven-archetype-quickstart.

Parent POMs

Wenn Sie mehrere Projekte haben, die ähnlich strukturiert sind, kann es sinnvoll sein, die Gemeinsamkeiten in einem neuen Projekt zusammenzufassen und dieses Projekt als Elternteil der Projekte zu definieren. Dies ist dem Java-Modell der Einfachvererbung sehr ähnlich. Diese Funktion ist sehr leistungsfähig, aber genau wie bei der Vererbung in Java sollte sie mit Bedacht eingesetzt werden.

Gut zu wissen: Jedes Projekt erbt letztendlich von der Maven Super POM.

Ein weiterer Tipp: Oft werden Parent POMs verwendet, um die Versionseinschränkungen zu zentralisieren (die normalerweise im Abschnitt “<dependencyManagement>” zu finden sind). Ein besserer Weg, Abhängigkeiten zu verwalten, ist die Verwendung eines separaten Moduls vom Typ “pom”, das diese Abhängigkeiten deklariert und die Versionen von dort importiert (unter Verwendung des Abhängigkeitsbereichs “import”). Auf diese Weise vermeiden Sie, dass Ihr übergeordnetes POM zu einer “Küchenspüle” wird, die alle Abhängigkeiten auflistet, die ein Unterprojekt jemals benötigt hat.

Aggregate Projects

Sie können ein Projekt in mehrere Module aufteilen, die durch ein aggregiertes POM verbunden sind. Die Erstellung dieses aggregierten Projekts baut automatisch die benötigten Module - auch wenn diese voneinander abhängen, da Maven die richtige Build-Reihenfolge bestimmt.

Schön: Parent POMs und Aggregate Projekte können kombiniert werden.

Fazit

Maven ist gut, also benutze es und denken nicht weiter darüber nach.