Apache Maven

Apache Maven
Basisdaten
Entwickler	Apache Software Foundation
Erscheinungsjahr	30. März 2002
Aktuelle Version	3.9.9 (18. August 2024)
Betriebssystem	Plattformunabhängig
Programmier­sprache	Java
Kategorie	Build-Management-Tool
Lizenz	Apache-Lizenz, Version 2.0
maven.apache.org

Apache Maven (kurz Maven) ist ein in der Programmiersprache Java geschriebenes Kommandozeilenwerkzeug aus der Kategorie der Build-Werkzeuge. Maven ist ein Top-Level-Projekt der Apache Software Foundation (ASF) und unter der freien Apache 2.0 Lizenz veröffentlicht.

In der offiziellen Dokumentation bezeichnet sich Maven als Projektmanagement-Werkzeug, da die Funktionen weit über das Erstellen (Kompilieren) der binär ausführbaren Artefakte aus dem Quellcode hinausgehen. Mit Maven können unter anderem auch Qualitätsanalysen von Programmcode und API-Dokumentationen erzeugt werden.

Maven wurde vornehmlich für die Java-Programmierplattform entwickelt und ist in integrierten Entwicklungsumgebungen für Java (z. B.: Apache NetBeans, Eclipse, IntelliJ IDEA) enthalten, sodass oftmals keine separate Installation notwendig ist.

Der Name Maven kommt aus dem Jiddischen und bedeutet so viel wie „Sammler des Wissens“.

Geschichte

Maven entstand in der Apache Software Foundation aus Frust über den Build-Prozess von Turbine. Es wurde bald zum Top-Level-Projekt aufgrund der Notwendigkeit, die Builds der vielen unterschiedlichen Projekte der Apache Software Foundation möglichst zu vereinheitlichen und somit auch zu vereinfachen.

Durch die vereinheitlichten Strukturen konnten Mitglieder unterschiedlicher Entwicklungsteams zwischen den einzelnen Teilprojekten wechseln und produktivere Arbeitsergebnisse erzielen. Dank der projektübergreifenden Standardisierung war es nicht mehr notwendig, sich in komplizierte Prozesse einzuarbeiten, um das Projekt ausführen und testen zu können.

Die Entwicklung von Maven 1 wurde im Jahr 2003 begonnen und am 13. Juli 2004 als Version 1.0 veröffentlicht. Die Umsetzung passierte jedoch sehr schnell, sodass einige Eigenheiten nicht bedacht wurden. Beispielsweise gab es Performanzprobleme sowie viele Konfigurationsdateien und -angaben, die es zu beherrschen galt. Am 18. Februar 2014 wurde das End of Life (EoL) von Maven 1 verkündet. Die letzte veröffentlichte Version ist 1.1 vom 25. Juni 2007.

Seit dem Jahr 2005 wurde parallel damit begonnen, Maven 2 zu entwickeln, welches in Version 2.0 am 19. Oktober 2005 fertiggestellt wurde. Mit dem Major-Release 2 wurde Maven von Grund auf überarbeitet und bekannte Probleme aus der Vorgängerversion behoben. Aus diesem Grund sind Maven 1 und Maven 2 nicht zueinander kompatibel. Am 18. Februar 2014 wurde das End of Life von Maven 2 verkündet. Letzte veröffentlichte Version ist 2.2.1 aus November 2009.

Die Entwicklung von Maven 3 begann im Jahr 2008. Maven 3.0 wurde am 8. Oktober 2010 veröffentlicht. Besonderes Augenmerk lag auf der Kompatibilität zwischen Maven 2 und 3.

In der zweiten Hälfte des Jahres 2021 wurden die Arbeiten an Maven 4 begonnen. Eine wesentliche Verbesserung wird die stark optimierte Unterstützung von Multi-Modul-Projekten.

Architektur & Design

Maven benötigt zur Ausführung eine Java virtuelle Maschine (JVM) und ist aufgrund dieses Umstandes plattformunabhängig. Daher kann Maven auf jedem Betriebssystem ausgeführt werden, für das eine Java VM verfügbar ist.

Der Kern von Maven ist mit wenigen MB als Download-Paket kompakt gehalten. Die interne Struktur ist modular aufgebaut. Sämtliche Funktionen werden über Erweiterungen, sogenannte Plugins, bei der erstmaligen Verwendung über ein öffentliches im Internet verfügbares Repository, Maven Central genannt, nachgeladen und in einem lokalen Repository abgelegt.

Es wird zwischen offiziellen Plugins, die unter der Hoheit des Maven-Projektes stehen, und anderen Plugins unterschieden. Letztere werden unter Umständen später auch zu offiziellen Plugins, Ende 2021 beispielsweise das maven-wrapper-plugin.

Es ist ebenso möglich, Maven durch selbst entwickelte Plugins zu erweitern. Aufgrund dieses Charakters wird es auch als Plugin Execution Framework bezeichnet.

Konzeptionelles

Maven ist deklarativ und basiert auf den beiden Paradigmen:

1. Don’t repeat yourself (DRY; dt. Übers.: Wiederhole dich nicht) bedeutet sinngemäß im Kontext von Maven, dass nicht bei jedem Projekt dieselben Build-Schritte neu definiert werden müssen.
2. Konvention vor Konfiguration (en: Convention over Configuration; CoC) bezieht sich auf die Konfigurationsdatei (POM), mit denen Maven-Projekte beschrieben werden. Durch festgelegte Konventionen haben möglichst viele Konfigurationseinträge gemeingültige Vorbelegungen (default-Werte), die für die meisten Anwendungsfälle bereits die erwünschten Ergebnisse produzieren.

Maven folgt den beiden beschriebenen Paradigmen über dem gesamten Zyklus der Softwareerstellung konsequent. Eine wichtige Voraussetzung für eine erfolgreiche Automatisierung der einzelnen Schritte des Softwareerstellungsprozesses sind strikte Vereinheitlichungen, wie sie durch die beiden Paradigmen DRY und CoC geschaffen werden.

Obwohl Maven bereits sehr viele Vorgaben macht, können Projekte diese Vorgaben an ihre tatsächlichen Bedürfnisse problemlos anpassen. Sowohl für künftige neuere Versionen von Maven als auch bei der Anbindung von Drittanbieterprodukten ist es eine bewährte Praxis, möglichst nahe am Maven-Standard zu bleiben.

Im Zusammenhang mit Maven werden wichtige Begriffe verwendet, die für das weitere Verständnis zunächst erläutert werden müssen:

Artifact (dt. Artefakt)

werden in Maven sowohl Plugins als auch Abhängigkeiten zu externen Programmbibliotheken und die selbst erstellten binären Programmdateien des eigenen Softwareprojektes bezeichnet.

Lifecycle (dt. Lebenszyklus)

kann auch als Workflow oder Prozess verstanden werden. Maven kennt drei Lifecycles: clean, site und build.

Phasen

werden die einzelnen Schritte innerhalb eines Lifecycle bezeichnet, die in festgelegter linearer Reihenfolge durchlaufen werden. Der Build-Lifecycle (default) kennt 23 Schritte.

Goal (dt. Ziel)

ist eine einzelne Aktion bzw. Funktionalität, die in einem Plugin bereitgestellt wurde.

Standard-Verzeichnisstruktur

Ein wesentliches Merkmal von Maven-Projekten ist eine einheitliche Verzeichnisstruktur, die im Nachfolgenden mit ihren wichtigsten Elementen kurz wiedergegeben wird.

my-project/ – Wurzelverzeichnis

pom.xml – Projektbeschreibung (Build-Logik)

src/ – alle Eingabedateien

main/ – Eingabedateien für die Erstellung des eigentlichen Produkts

java/ – Java-Quelltext-Dateien

resources/ – Projektdateien, die kein Java-Quellcode sind, aber für die Übersetzung oder zur Laufzeit benötigt werden, z. B. Bilder, SQL, Java-Properties-Dateien etc.

test/ – Eingabedateien, die für automatisierte Testläufe benötigt werden

java/ – Testfälle, die als Java-Quellcode vorliegen, z. B. JUnit-Testfälle

resources/ – Zusätzliche Ressourcen für Testfälle

target/ – Alle durch Maven während des Build-Vorgangs erstellten Dateien

classes/ – kompilierte Java-Klassen

Das target-Verzeichnis hat eine besondere Rolle inne, hier werden alle von Maven während des Build-Vorgangs erzeugten Dateien wie beispielsweise Kompilate abgelegt. Dieses temporäre Verzeichnis wird üblicherweise durch die Projekte aus den Revisionen von Source-Control-Management-Systemen wie Git ausgeklammert.

Die wichtigsten Verzeichnisse wie beispielsweise das Wurzelverzeichnis (${basedir}) oder auch das Ausgabeverzeichnis (${outputdir}) können über durch Maven bereits vordefinierte Properties angesprochen werden. Diese Praxis sollte gegenüber der Verwendung von festen Verzeichnispfaden bevorzugt werden, da dies die Portierbarkeit von Projekten ermöglicht.

Automatisiertes Erstellen eines neuen Maven-Projektes mit Archetypen

Mit Maven-Archetypen (archetypes) können Gerüste für unterschiedlichste Arten von Softwareprojekten erstellt werden, deren Struktur dem Standard von Maven entspricht.

mvn archetype:generate \
  -Darchetype.interactive=false \
  -DarchetypeGroupId=org.apache.maven.archetypes \
  -DarchetypeArtifactId=maven-archetype-quickstart \
  -DarchetypeVersion=1.4 \
  -DgroupId=org.sample.archetypes \
  -DartifactId=sampleproject \
  -Dversion=1.0-SNAPSHOT \
  -Dpackage=jar

Die Konfigurationsdatei: pom.xml

Die Konfigurationsdatei für Maven-Projekte hat die offizielle Bezeichnung „Project Object Model (POM)“ und ist als pom.xml im Wurzelverzeichnis des Projektes abgelegt. Im Kontext des Build-Managements ist die pom.xml die Build-Logik, welche von externen Werkzeugen wie dem Automatisierungsserver Jenkins aufgerufen wird.

Die zwingenden Basisangaben für ein Maven-Projekt innerhalb einer POM sind die sogenannten GAV-Parameter, zuzüglich des Packagetyps. GAV steht für (G) = groupID, (A) = artifactId und (V) = version. Die GAV-Koordinaten müssen für jedes Maven-Projekt eindeutig sein und dürfen nicht mehrfach Verwendung finden.

<?xml version="1.0" encoding="UTF-8"?>
<project>
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.sample</groupId>
    <artifactId>project-name</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom | jar | war | ear </packaging>
</project>

Listing1: Minimal POM

Auflösung von Abhängigkeiten (Dependency Management)

Einer der wichtigsten Faktoren für den Erfolg von Maven ist der einfache Umgang mit fremden Abhängigkeiten, sogenannten 3rd Party Libraries. Externe Abhängigkeiten werden in der pom.xml notiert und über ihre GAV-Koordinaten eindeutig und transitiv aufgelöst. Die in Maven definierten Abhängigkeiten werden nicht mehr physisch in die Versionsverwaltung mitaufgenommen, sondern während des Buildvorgangs im Projekt-Ausgabeverzeichnis target bereitgestellt.

Bei der Verwendung eines Artefaktes prüft Maven, ob es bereits lokal im Repository vorhanden ist. Das lokale Repository ist ein verstecktes Verzeichnis mit der Bezeichnung .m2/repository und findet sich im home-Verzeichnis des am Betriebssystem angemeldeten Nutzers.

Kann Maven das angeforderte Artefakt im lokalen Repository nicht finden, wird in einem öffentlichen Remote-Repository danach gesucht. Bei erfolgreicher Suche wird das Artefakt im lokalen Repository verfügbar gemacht. Das wichtigste öffentlich frei verfügbare Repository für Java-Artefakte lautet „Maven Central“ und wird von dem Unternehmen Sonatype betrieben.

Es besteht die Möglichkeit, einen eigenen Repository-Server zu betreiben, um selbst erstellte Artefakte im Unternehmen im Intranet für andere Projekte bereitzustellen oder diese über das Internet verfügbar zu machen.

Wichtige Implementierungen zum Hosten eigener Artefakte sind Sonatype Nexus OSS oder JFrog Artifactory, für die es sowohl freie Community Versionen als auch kommerzielle Enterprise-Varianten gibt. Diese Lösungen können neben den verschiedenen Java-Artefakten auch andere Formate wie beispielsweise Docker Images, RubyGems, .NET nuget oder NPM verwalten. Maven Central, das größte Open-Source-Repository, wird mit Nexus OSS betrieben.

Maven-Lebenszyklen (Lifecycle)

Die Maven-Lebenszyklen sind:

• clean zum Löschen von Ergebnissen vorheriger Builds, mit den Phasen pre-clean, clean, post-cl
• build (default) zum Erstellen des Projekts im Rahmen der untengenannten Phasen,
• site zum Erstellen von Webseiten zur Projektdokumentation und Reports, mit den Phasen pre-site, site, post-site, site-deploy.

Maven geht dabei jeweils von einem Zyklus aus, der bei der Softwareerstellung im Allgemeinen durchlaufen wird. Es muss aber nicht jedes Softwareprojekt alle Phasen des im Folgenden verkürzt dargestellten default-Zyklus verwenden. Die Standardfunktionalität kann durch die Einbindung von zusätzlichen Maven-Plug-ins an die entsprechende Phase erweitert werden.

validate (Validieren)

Es wird überprüft, ob die pom.xml und die Projektstrukturen vollständig, valide und gültig sind.

compile (Kompilieren)

In dieser Phase wird der Quellcode kompiliert.

test (Testen)

Hier wird der kompilierte Code durch das eingebundene Unit-Test-Framework (z. B. JUnit, TestNG) getestet. Maven berücksichtigt dabei in späteren Zyklen, dass Testklassen normalerweise nicht in der auszuliefernden Software vorhanden sind.

package (Verpacken)

Das Kompilat wird – ggf. mit anderen nicht kompilierbaren Dateien – zur Weitergabe verpackt. Häufig handelt es sich dabei um eine JAR-Datei.

integration-test (Integrationstests)

Bereitstellen der programmatisch erstellten Integrationstests mittels Behavior Driven Development (z. B. Cucumber, jGiven).

verify (Gültigkeitsprüfung des Softwarepakets)

Überprüfung der Artefakte, ob die festgelegten Spezifikationen erfüllt wurden, d. h. die bereitgestellten Integrationstests werden ausgeführt.

install (Kopieren ins lokale Maven-Repository)

Kopiert das Softwarepaket ins lokale Maven-Repository, um es dann in anderen lokalen Maven-Projekten verwenden zu können. Dies ist insbesondere für modulare Projekte von Bedeutung.

deploy (Hochladen in ein entferntes Maven-Repository)

Lädt das Softwarepaket in ein entferntes Maven-Repository hoch, wonach es auch anderen Entwicklern zur Verfügung steht, mitunter auch weltweit.

Teilprojekte

Die Entwicklung von Maven ist in verschiedene Teilprojekte untergliedert:

• Maven 1 und Maven 2 werden seit Februar 2014 nicht mehr weiterentwickelt.
• Maven 3 stellt den aktuellen Entwicklungszweig der Core-Entwicklung dar.
• Plugins entwickelt die meisten Maven-Plug-ins.
• Shared Components stellt Softwarekomponenten bereit, die von den anderen Teilprojekten verwendet werden können.
• Antrun ermöglicht es, Tasks aus Ant-Skripten in Maven zu verwenden.
• Doxia ist ein Framework zum Generieren von Content aus den Formaten Almost Plain Text (APT), Confluence, DocBook, FML (FAQ Markup Language), LaTeX, Markdown, Rich Text Format (RTF), TWiki, XDoc und XHTML.
• SCM (Source Code Management) entwickelt Software für die Anbindung von Apache an verschiedene Systeme zur Versionsverwaltung wie Git, Subversion oder CVS.
• Surefire entwickelt eine Umgebung zum Ausführen von Unit-Tests in Maven.
• Failsafe entwickelt eine Umgebung zum Ausführen von Integrations-Tests in Maven.
• Wagon stellt eine Abstraktionsschicht für Kommunikationsprotokolle wie „Dateizugriff“, HTTP oder FTP bereit.

Siehe auch

• Apache Ant, Gradle konkurrierende Build Tools für Java
• Apache Ivy, Tool zur Verwaltung von Abhängigkeiten
• Jenkins, Travis CI, Automatisierungsserver (CI Server)

Literatur

• Vincent Massol, Jason van Zyl, Brett Porter, John Casey, Carlos Sanchez: Better Builds with Maven. How-to Guide for Maven 2.0. Hrsg.: Exist Global. August 2007 (wisc.edu [PDF]). 
• Kai Uwe Bachmann, Maven 2, Addison-Wesley, 2009, ISBN 978-3-8273-2835-9, (deutsch).
• Tim O’Brien, Jason van Zyl, Brian Fox, John Casey, Juven Xu, Thomas Locher: Maven: By Example. An Introduction to Apache Maven. Hrsg.: Sonatype. Mountain View, California 2010, ISBN 978-0-9842433-3-4 (sonatype.com). 
• Tim O’Brien, Jason van Zyl, Brian Fox, John Casey, Juven Xu, Thomas Locher: Maven: The Complete Reference. Hrsg.: Sonatype. Mountain View, California 2010, ISBN 978-0-9842433-4-1 (sonatype.com). 
• Martin Spiller, Maven 3: Konfigurationsmanagement mit Java, mitp Verlags GmbH & Co. KG, 2011, ISBN 978-3-8266-9118-8 (deutsch).
• Srirangan, Apache Maven 3 Cookbook, Packt Publishing, 2011, ISBN 978-1-84951-244-2.
• Balaji Varanasi, Introducing Maven: A Build Tool for Today’s Java Developers, 2nd ed. edition, Apress, 2019, ISBN 978-1-4842-5409-7.

Weblinks

• Maven Website (englisch)
• Maven Central, das zentrale öffentliche Maven-Repository
• OSSRH Guide, Anleitung zum Veröffentlichen von Artefakten auf Maven Central (englisch)
• Einführung in Maven, Konferenzvortrag IT-Tage Frankfurt 2020 (deutsch)
• Plugins auf der Codehaus-Homepage (englisch). 13. April 2013, archiviert vom Original (nicht mehr online verfügbar) am 14. April 2013; abgerufen am 22. Juli 2017.