Wenn es um das Thema Maven geht scheiden sich die Geister, bzw. Entwickler in Maven-Liebhaber und Maven-Hasser. Dazwischen scheint es nichts zu geben. Für die einen ist es ein unverzichtbares Hilfsmittel, um Projekten eine einheitliche Struktur zu geben und einen neuen Entwickler im Team schnell an ein ihm unbekanntes Projekt heranzuführen. Andere schreckt die Konfiguration ab, da viel über Maven und das ihm zugrundeliegende Vorgehensmodell bekannt sein muss, um es effektiv nutzen zu können. In Ant gibt der Entwickler die einzelnen Arbeitsschritte in leicht verständlichen Befehlen selbst an (kopieren, kompilieren, packen etc.), während das in Maven in elementaren Teilen automatisch gemacht wird und man nur noch in bestimmten Stellen im Prozess, wenn nötig, weitere Schritte hinzufügt. Stichwort: Build Lifecycle, Scope und Phase.

Das folgende Tutorial soll eine Einführung in Maven geben und evtl. als Entscheidungshilfe dienen, ob es eingesetzt werden soll.

Los geht’s…

1. Als Minimalanforderung ist das J2SE 1.5 angesagt.

Wir laden Maven herunter und installieren es von http://maven.apache.org/download.html.
Für Windows empfiehlt es sich die .zip-Datei herunterzuladen (apache-maven-3.0.3-bin.zip), unter Linux/MacOS sollte man zur .tar.gz-Datei greifen (apache-maven-3.0.3-bin.tar.gz).

2. Anschließend müssen wir die Datei in einem Verzeichnis entpacken:

Es hat sich bewährt, die Versionsnummer im Verzeichnisnamen bestehen zu lassen:

Windows:
Wir entpacken die Datei unter C:\Java. Das Maven-Wurzelverzeichnis lautet damit dann C:\Java\apache-maven-3.0.3 .

Linux / Mac OS X, in der Shell:

… entpackt den Inhalt der Datei unter /Users/<USERNAME>/Java. Das Wurzelverzeichnis lautet dann /Users/<USERNAME>/Java/apache-maven-3.0.3.

Dieses Wurzelverzeichnis, M2_HOME genannt, müssen wir jetzt noch über eine Umgebungsvariable systemweit bekannt machen.

Windows XP / 7:
Wir gehen auf „Start > Ausführen“ und geben „sysdm.cpl“ und ENTER ein.
Im Reiter „Erweitert“ klicken wir auf „Umgebungsvariablen“. Unter „Benutzervariablen für <USERNAME>“ erstellen wir mit „Neu“ eine neue Benutzervariable, die wir M2_HOME nennen. Als Wert der Variable geben wir C:\Java\apache-maven-3.0.3 an
Anschließend legen wir eine weitere Benutzervariable an, die wir M2 nennen. Als Wert geben wir C:\Java\apache-maven-3.0.3\bin an.
Schließlich müssen wir Maven noch in den Pfad aufnehmen, so dass wir von jedem Verzeichnis aus per Eingabe von „mvn“ Maven starten können, ohne den Pfad angeben zu müssen. Dazu einfach die Systemvariable PATH bearbeiten und den Wert der Variablen um den Eintrag %M2% ergänzen. Es muss darauf geachtet werden, dass vor dem %M2% ein Semikolon steht, um die einzelnen Pfadeinträge voneinander zu trennen. Falls davor kein Semikolon steht: einfach hinzufügen und auf Ok klicken.
Wenn das alles erledigt ist prüfen wir, ob Maven jetzt korrekt konfiguriert ist. Dazu gehen wir in ein DOS-Fenster (Start > Ausführen > cmd.exe und ENTER drücken) und tippen „mvn --version“ ein. Als Ergebnis erhalten wir in etwa „Apache Maven 3.0.3...„.
Achtung: ein bereits geöffnetes DOS-Fenster „sieht“ die Ergänzungen der Umgebungsvariablen nicht. Es muss ein neues DOS-Fenster geöffnet werden ,damit es korrekt mit den neuen und geänderten Umgebungsvariablen initialisiert werden kann.

Linux / Mac OS X, in der Shell:
Wir öffnen und bearbeiten die Datei ~/.bashrc und erweitern, bzw. ergänzen, sie um folgende Einträge:

3. Wir bleiben in diesem DOS-Fenster und legen jetzt ein einfaches Maven-Projekt an:

Windows XP / 7:

Linux / Mac OS X:

Folgend eine kurze Erläuterung der Parameter:

archetype:generate
Dieser Parameter gibt an, dass ein neues Maven-Projekt angelegt werden soll.

-DgroupId=de.theserverside
Dies ist, ähnlich wie in den Java-Packagestrukturen, nur eine Info, um das Projekt innerhalb einer größeren Menge von Projekten gruppieren zu können. Es hat sich etabliert, auch hier die Syntax TLD.DOMAIN.IRGENDETWAS zu verwenden. Allerdings gibt es auch Projekte, speziell im Open-Source Umfeld, die sich nicht daran halten und nur den Namen des Projekts verwenden. Beispiel: Log4J, wo die groupId einfach nur „log4j“ lautet.

-DartifactId=meinprojekt
Hiermit benennen wir das Projekt, bzw. Modul. Für gewöhnlich ist das der „offizielle“ Name des Projekts, also im Falle von Log4J wäre es z.B. „log4j“.

-DarchetypeArtifactId=maven-archetype-quickstart
Der „Archetyp“ des Projekts, also um welche *Art* von Projekt es sich handelt wird hiermit angegeben. Hiermit sagen wir, dass eine simple Maven-Standardverzeichnisstruktur anzulegen ist, für ein normales Java-Projekt. Wir könnten auch einen anderen Archetypen angeben, z.B. um ein Spring- oder JSF-Projekt anzulegen, und die Verzeichnisstruktur würde erweitert werden um weitere Unterverzeichnisse und rudimentär angelegte Konfigurationsdateien. Im Falle eines Webprojekts würde z.B. ein WEB-INF Verzeichnis mit einer einfachen „web.xml“ angelegt werden, die wir dann nur noch um unsere eigenen Einträge ergänzen müssen.

-DinteractiveMode=false
Hiermit geben wir an, dass bei der Ausführung des Befehls nichts weiter abgefragt werden und der Befehl „am Stück“ ausgeführt soll.

Als Ausgabe erhalten wir:

Zwischen dem Beginn und dem „BUILD SUCCESSFUL“ finden sich auch Download-Meldungen, falls Maven eine bestimmte Funktionalität (z.B. ein Archetyp) gefehlt hat und es sich das erst nachträglich dazuinstallieren musste nachdem es aus dem Internet von einer bestimmten Adresse (genannt: Repository) heruntergeladen wurde.

4. Wir schauen uns das generierte Projekt an und finden folgende Verzeichnisstruktur:

Folgendes ist hier geschehen: Maven hat für uns ein Standardprojekt mit dem Maven-Standardverzeichnislayout („Standard Directory Layout“) angelegt. Hier legt Maven für uns fest, wo die Sourcen liegen, wo evtl. benötigte Resourcen liegen (XML-Konfigurationsdateien etc.) und wo sich die Testklassen befinden sollen. Diese Verzeichnisstruktur ist das Herzstück Mavens, denn darüber weiß Maven wo die für die einzelnen Buildschritte zu verarbeitenden Dateien liegen. Maven wird also in der Kompilierphase immer alles kompilieren, was es unter src/main/java findet. Bei Ausführung von Testklassen wird es diese immer unter test/ suchen, kompilieren und ausführen.

Wie wir sehen hat uns Maven auch zwei Klassen angelegt: App.java und AppTest.java. Diese beinhalten über eine „Hello World“-Ausgabe und einen rudimentären JUnit-Tests hinaus nichts weiter und dienen nur dazu, zu veranschaulichen, wo welche Art von Dateien abzulegen sind.

5. Die Projektdatei „pom.xml“:
Interessant wird es hingegen bei der pom.xml, die unsere eigentliche Projektdatei darstellt. Sie darf nicht umbenannt oder verschoben werden, da Maven ansonsten, für dieses Projekt, nicht korrekt arbeitet.

Wenn wir einen Blick hineinwerfen sehen wir folgenden Inhalt:

Die ersten drei Zeilen enthalten die üblichen Angaben zu XML-Dateien. In „modelVersion“ wird angegeben, dass es sich mit dieser Datei um die Version 4.0.0 des Formats für Mavenprojektdateien handelt.
Bei groupId und artifactId handelt es sich um die Angaben die wir bei der Anlage des Projekts vorgenommen haben.
Mit packaging sagen wir aus, welche Art von Datei am Ende des Buildprozesses erstellt werden soll. In diesem Fall wird eine .jar-Datei angelegt. Wenn wir hier „war“ eintragen würden alle für eine .war-Datei benötigten Komponenten (WEB-INF, web.xml etc.) nach dem kompilieren zusammengesammelt und in eine .war-Datei gepackt werden die wir z.B. in den Tomcat deployen.
Die version sagt aus, dass es sich zwar um die Version 1.0 der Anwendung handelt, diese aber ein SNAPSHOT ist, d.h. sich inhaltlich ständig ändern kann. Wenn wir das SNAPSHOT entfernen und wir es als „Release“ herausgeben (dazu später mehr) garantieren wir anderen Entwicklern damit, dass sich der Code in der Datei nicht mehr ändert. Bei einem SNAPSHOT hingegen ist noch Vorsicht geboten.
Der name ist der bei der Anlage des Projekts vergebene Name und sollte auf etwas lesbareres geändert werden, z.B. „Mein 1. Mavenprojekt“.
Die url kann auch frei vergeben werden, hier könnten wir z.B. http://theserverside.de eintragen.

6. Dependency Management
Interessant wird es bei den dependencies, das herausragende und wichtigste Merkmal bei Maven. Hier geben wir an, wann welche Libraries in unserem Projekt benötigt werden. In diesem Fall geben wir an, dass unser Code junit in der Version 3.8.1 verwendet. Allerdings ist als scope der Wert test angegeben. Damit sagen wir aus, dass diese Library nur benötigt wird, wenn wir Maven instruieren, die Testklassen auszuführen. Wenn das .jar zum deployen gebaut wird soll die JUnit-Library nicht mit in die erzeugte Datei aufgenommen werden. Alternativ wäre es im Falle einer Webanwendung (package-Angabe „war„) beispielsweise auch unsinnig, die JUnit-Library mit einzubinden, da Tests für gewöhnlich immer in der Konsole gestartet werden, vor dem Deployment, und nichts in der fertig deployten Anwendung, sprich: in der .war-Datei, zu suchen hat.

Als Maven-Neuling denkt man sich jetzt, dass diese Dependency-Angabe ja nun sehr aussagekräftig und interessant ist, aber was macht Maven damit und wo holt es JUnit her? Die Antwort ist ganz einfach: JUnit wird aus dem Internet heruntergeladen. Es gibt mehrere offizielle „Repositories“, beispielsweise http://repo1.maven.org/, wo sich riesige Sammlungen bekannter Libraries in ihren verschiedenen Versionen befinden. Alle mehr oder weniger bekannten OpenSource-Projekte sind dort vertreten und werden auch regelmäßig aktualisiert. Identifiziert werden sie über ihre „Maven-Coordinates“, das sind, um das Thema abzurunden, die Angaben groupId, artifactId und version.

7. Das lokale Repository
Jetzt stellt man sich zurecht die Frage, ob die Dependencies jedes Mal von neuem heruntergeladen werden. Wenn ich drei Projekte auf meinem Rechner anlege hieße das ja auch, dass er für jedes der Projekte JUnit 3.8.1 herunterlädt. Diese Trafficlast wäre von den offiziellen Repositories gar nicht zu tragen und daher sorgt Maven auch hier vor. Unter dem Benutzerverzeichnis, unter Windows wäre das C:\Dokumente und Einstellungen\<USERNAME> und auf dem Mac ~/, wird ein Verzeichnis .m2 angelegt, welches nicht nur eine benutzerspezifische Konfigurationsdatei settings.xml enthält, sondern auch ein lokales Repository. Dort wird, identisch zu der Struktur in den offiziellen Repositories und damit auch gemäß der Maven-Coordinates der jeweiligen Library, alles abgelegt was heruntergeladen wurde. Das schließt auch Maven-eigene Plugins ein. Wenn also eine neue Dependency in einer pom.xml entdeckt wird und diese nicht im lokalen Repository liegt wird sie aus dem Internet heruntergeladen und im lokalen Repository, zur systemweiten Verwendung für alle Maven-Projekte, abgelegt.

8. Jetzt wird gebaut…
Nach diesem Überblick wollen wir unser Projekt „bauen“, also kompilieren und paketieren, lassen. In der Konsole geben wir dazu im Wurzelverzeichnis unseres Projekts folgendes ein:

Als Ausgabe erhalten wir:

Aus den Ausgabemeldungen sieht man, dass Maven, u.A., alle eventuell vorher erzeugten Kompilate und Buildartefakte löscht, das Projekt kompiliert, die Testklassen kompiliert, die Tests startet und das Ganze als .jar-Datei packt und unter C:\Java\meinprojekt\target\meinprojekt-1.0-SNAPSHOT.jar ablegt.

Diese verschiedenen Schritte folgen festgelegten „Phasen“ im Maven-Buildprozess und wir können uns an den verschiedenen Stellen, über Einträge in der pom.xml „einhaken“. Dazu eventuell später mehr in einem Folgeartikel, aber für einen Einstieg in den Build Lifecycle empfiehlt sich erst einmal der folgende Link aus der Maven Dokumentation Introduction to the Build Lifecycle.

Die .jar-Datei die wir erhalten haben, meinprojekt-1.0-SNAPSHOT.jar, könnten wir über Maven-Befehle auch wieder in unser Repository, oder ein Unternehmensrepository, deployen und dort anderen Entwicklern zur Verfügung stellen. Hätten wir uns eine .war-Datei generieren lassen könnten wir diese z.B. direkt in den Tomcat deployen, oder Maven diese deployen lassen, und die Anwendung sofort testen. Maven ist in diesen Punkten sehr stark erweiterbar und man kann als Entwickler in jede Phase des Buildprozesses eingreifen und diesen anpassen.

9. Und was ist mit der IDE?
Natürlich soll diese nicht zu kurz kommen und auch hier lässt Maven uns nicht im Stich. Einfach in der Konsole folgendes eingeben:

… und wir erhalten eine .project und die dazu passende .classpath-Datei, die wir einfach im Eclipse importieren. Analog gibt es auch den Befehl, in Maven-Sprache „target“, mvn idea:idea für IntelliJ IDEA Projektdateien.

Weiterführende Literatur
„Maven ist ein Biest“, das muss man ganz klar sagen. Die Abneigung speist sich zum größten Teil aus Unwissenheit über den Build Lifecycle. Ohne diesen zu verstehen gestaltet sich eine Anpassung abweichend vom Maven-Standardvorgehen als sehr schwierig. Ist das einmal gezähmt möchte man Maven nicht mehr missen und Ant nicht mehr anfassen müssen.

Für die Zähmung unverzichtbar war für mich Apache Maven 2 Effective Implementation von Brett Porter und Maria Odea Ching. Das Buch ist zwar auf Englisch und behandelt Maven 2, es ist aber sehr verständlich geschrieben und praktisch alles was sich dort findet gilt auch für die aktuelle dritte Version von Maven. Ein weiterer Vorteil ist, dass das Buildmanagement als geschlossene Einheit behandelt und auch auf Continuum und Archiva detailliert eingegangen wird.

Das deutschsprachige Buch Maven 3: Konfigurationsmanagement mit Java von Martin Spiller, welches sich mit Maven 3 beschäftigt, ist sicherlich auch einen Blick wert. Da es noch nicht erschienen ist (Stand: 19.07.2011) kenne ich es noch nicht, es ist aber das meines Wissens erste deutschsprachige Buch zu Maven 3 und ich werde bald einen Blick riskieren.

Weitere Empfehlungen: