Build Management mit Maven

Komplexe Entwicklungsprojekte, die aus mehreren tausend Dateien bestehen können, sind ohne Hilfsprogramme und Tools kaum mehr handhabbar. Um aus den vielen zusammenspielenden Teilen eine lauffähige Software zu erstellen, das Deployment vorzunehmen und ähnliche Verwaltungsaufgaben durchzuführen, gibt es eine Reihe von Build Management Tools, die die hierfür erforderlichen Schritte automatisiert durchführen. In diesem Artikel soll mit dem Apache Maven-Projekt das derzeit aktuellste Build Managemant Tool aus dem Open Source Java-Bereich vorgestellt werden.

Entwicklung

Das Maven-Projekt ist neben dem stark verbreiteten Ant ein zweites Build Management Tool der Apache Group. Zusätzlich zu den eigentlichen Aufgaben des Build Managements verfolgt Maven den Ansatz des Best Practice, in dem verschiedene Standardisierungen vorgegeben werden, die vor allem bei größeren Projekten zu einer Vereinheitlichung und Vereinfachung führen sollen. Während die erste Version von Maven (Maven 1.x) noch stark an Ant angelehnt war, verfolgt die zweite Version einige grundlegend neue Ansätze und ist nicht mehr mit der vorherigen Version kompatibel.

Installation und Konfiguration

Abb. 1: Standard Projektverzeichnis für ein Maven-Projekt.

Die Programmdateien werden von der Apache Group als Zip-Archiv zum Download angeboten [1]. Eine Installation im eigentlichen Sinne ist nicht erforderlich. Es genügt, das Zip-Archiv auf der Festplatte zu entpacken. Im Anschluss daran müssen jedoch einige Umgebungsvariablen angelegt beziehungsweise angepasst werden:

1. Anlegen der Umgebungsvariable M2_HOME: Pfad zu dem Verzeichnis, in das das Archiv entpackt wurde (z. B. "C:\Programme\ maven2.0.7")
2. Anpassen der Umgebungsvariablen Path: Pfad zum bin-Verzeichnis der Maven-Installation (z. B. "%M2_HOME%\bin")
3. Installation eines JDK in der Version 1.5 oder höher
4. Die Umgebungsvariable JAVA_HOME korrekt setzen (z. B. "C:\Programme\Java\ jdk1.5.0_12")

Wenn diese vier Schritte vollzogen sind, kann Maven verwendet werden. Ein erster Testaufruf von mvn-version gibt die aktuell auf dem Rechner verfügbare Version des Tools aus.

Erstellen eines neuen Projektes

Einer der Grundgedanken von Maven besteht darin, ein einheitliches, standardisiertes Projektverzeichnis zu verwenden. Für das Erstellen neuer Projekte stellt Maven einen Mechanismus zur Verfügung, der eine leere Standard-Verzeichnisstruktur erzeugt (siehe Abbildung 1). Hierfür gibt es verschiedene Archetypes, eine Art Templates, anhand derer Ordnerstrukturen und vordefinierte Inhalte für verschiedene Projektarten erstellt werden können. Der Archetype create erstellt ein Standardprojekt (siehe Abbildung 2).

Der Package-Name des neu zu erstellenden Projektes (groupId), sowie der Name des Projektes (artifactId) werden mit dem Präfix -D als Parameter übergeben. Der Wert des Parameters archetype gibt das zu verwendende Template an.

Neben der Verwendung bereits vorhandener Archetypes besteht die Möglichkeit, eigene Archetypes zu erstellen und zu verwenden. Somit können zusätzliche Basisklassen oder Konfigurationen bereitgestellt oder gänzlich neue Projektstrukturen definiert werden.

mvn archetype:create -DgroupId=de.ordix.test
-DartifactId=Testprogramm

<project xmlns="http://maven.apache.org/POM/4.0.0"
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
				http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>de.ordix.test</groupId>
	<artifactId>Testprogramm</artifactId>
	<packaging>jar</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>Testprogramm</name>
	<url>http://www.ordix.de</url>
	<dependencies>
		<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>3.8.1</version>
		<scope>test</scope>
		</dependency>
	</dependencies>
</project>

Konfigurationsdatei pom.xml

Während es in Ant-Projekten die build.xml gibt und Maven 1.x eine projektspezifische projekt.xml erstellt, heißt die projektspezifische Konfigurationsdatei für Maven2-Projekte pom.xml. Bei der Erstellung eines neuen Projektes unter Verwendung eines Archetypes wird automatisch eine pom.xml erstellt, in der die Grunddaten des Projektes enthalten sind (siehe Abbildung 3).

In dem Standardprojekt wird bereits eine Startklasse mit einer "Hello World"-Ausgabe kreiert und eine JUnit-Testklasse hierfür erstellt. Da für die Ausführung die JUnit-Bibliothek benötig wird, ist diese bereits in der pom.xml als Dependency eingetragen.

Weitere Bibliotheken können entsprechend eingebunden werden: also unter Angabe der artifactId und groupId, unter der sie im verwendeten Repository zur Verfügung stehen, sowie gegebenenfalls der Versionsnummer, die verwendet werden soll.

Erweiterung durch Plugins

Maven 2 hält an dem Grundgedanken eines modularen Aufbaus weiterhin fest. Dieser ermöglicht es, beliebige Funktionen durch Plugins hinzuzufügen. Um ein Plugin in das Projekt zu integrieren, reicht es in der Regel aus, dieses in der pom.xml zu definieren und dort ggf. noch einige Parameter zu setzen.

Allerdings können Maven 1.x-Plugins von der aktuellen 2er-Version nicht verwendet werden. Und umgekehrt sind Plugins, die für die neue Maven-Version erstellt wurden, nicht abwärtskompatibel. Dies führte vor allem in der Anfangszeit der neuen Maven-Version dazu, dass verschiedene, bewährte Plugins in der zweiten Version nicht mehr zur Verfügung standen.

Mittlerweile stehen aber für die allermeisten Maven 1.x-Funktionen auch entsprechende Plugins für Maven 2 bereit.

Ein Plugin als Beispiel

<plugin>
	<groupId>org.codehaus.cargo</groupId>
	<artifactId>cargo-maven2-plugin</artifactId>
	<configuration>
	</configuration>
</plugin>

Eine der häufigsten Aufgaben für ein Build-Tool ist das Steuern eines Web-Containers bzw. eines Application Servers sowie das Deployment des Projektes. Hierfür stellt die Open Source Community Codehaus mit dem Cargo-Plugin eine Lösung zur Verfügung, die diese Aufgaben für eine Vielzahl an Containern übernimmt. Die Integration des Plugins in der pom.xml zeigt Abbildung 4.

Neben den Pflichtangaben der artifactId und der groupId hätten hier zusätzlich noch eine Versionsnummer und Plugin-abhängige Parameter (wie z. B. die URL zum Container) angegeben werden können.

Ein Plugin kann mehrere Funktionalitäten haben, die über verschiedene, so genannte Goals angesprochen werden können. Der Aufruf einer solchen Plugin-Funktion setzt sich also aus dem Plugin und dem Goal zusammen. Die wichtigsten Funktionalitäten des Cargo-Plugins lassen sich also wie folgt aufrufen:

Starten des Containers: cargo:start
Stoppen des Containers: cargo:stop
Deployment des Projektes: cargo:deploy

Neben der Integration bestehender Plugins können auch eigene Plugins erstellt und verwendet werden. Auch hier hilft ein Maven Archetype, der ein leeres Plugin-Projekt mit der erforderlichen Minimalkonfiguration erstellt.

Das zentrale Repository

Ein weiterer Grundgedanke des Maven-Projektes besteht darin, sämtliche Bibliotheken und Plugins an einer zentralen Stelle zu verwalten, anstatt die benötigten Archive den jeweiligen Projekten einzeln zuzuordnen. Dieses Konzept vereinfacht vor allem bei der Arbeit mit mehreren Projekten den Verwaltungsaufwand, da alle Plugins und Bibliotheken nur an einer Stelle gespeichert, gepflegt und ggf. aktualisiert werden.

Die Apache Group bietet hierfür ein zentrales Repository an, in dem eine ganze Reihe von Standardbibliotheken (wie z. B. Log4J, JUnit oder JDom) zur Verfügung gestellt werden. Sie stellt weiterhin zentrale Repositories für Plugins bereit. Von den Repositories der Apache Group gibt es übrigens eine Reihe von Spiegeln, die alternativ verwendet werden können, um Verfügbarkeitsengpässe zu vermeiden.

Maven lässt neben der Verwendung der Apache Repositories auch die Nutzung selbst erstellter Repositories zu. Dies hat den Vorteil, dass für den Zugriff auf das Repository keine Internet- Verbindung notwendig ist. Zudem lässt sich dadurch beispielsweise eine firmenweite, projektübergreifende Bibliothekensammlung erstellen, aus der alle Projekte ihre benötigten Ressourcen beziehen.

Hierbei kann auch auf mehrere Repositories gleichzeitig zugegriffen werden. Die zu verwendenden Repositories werden einfach in den Konfigurationsdateien des Tools angegeben.

Ein entscheidender Vorteil der zentralen Repositories liegt darin, dass Abhängigkeiten zu anderen Bibliotheken bereits im Repository hinterlegt sind und nicht mehr manuell eingebaut werden müssen. Um also eine Bibliothek A einzubauen, die ihrerseits die Bibliotheken B und C benötigt, genügt es, A als Dependency anzulegen. Die abhängigen Bibliotheken B und C werden bei einem Build automatisch berücksichtigt.

Leider funktioniert dieses Prinzip nicht immer fehlerfrei und es kommt gelegentlich zu unerwünschten Nebeneffekten. In der Regel reicht es aber aus, das lokale Repository im .m2-Verzeichnis zu löschen, damit Maven alle Archive noch mal neu herunterlädt.

Das Maven-Verzeichnis

Bei der ersten Verwendung von Maven erzeugt das Tool auf dem lokalen Rechner einen Ordner, in dem ein lokales Repository sowie die Konfigurationsdatei settings.xml untergebracht sind. Standardmäßig wird hierfür ein .m2-Ordner im Home-Verzeichnis des Users angelegt.

Im lokalen Repository wird eine Kopie aller Dateien und Bibliotheken abgelegt, die für die Ausführung einer Task aus einem entfernten Repository heruntergeladen wurden. Wenn dieselbe Task nun ein zweites Mal ausgeführt wird, wird dabei die lokale Kopie des benötigten Archivs benutzt, anstatt es erneut aus der entfernten Quelle herunterzuladen. Erst wenn neue Bibliotheken eingebunden oder eine aktuellere Version einer bestehenden Bibliothek verwendet werden sollen, müssen diese vom entfernten Repository heruntergeladen werden.

Die Konfigurationsdatei settings.xml

<profile>
	<id>testProfile</id>
	<activation>
		<property>
			<name>Skip_Test</name>
		</property>
	</activation>
	<properties>
		<maven.test.skip>true</maven.test.skip>
	</properties>
</profile>

Die settings.xml stellt neben der projektspezifischen Konfigurationsdatei pom.xml eine zweite, projektübergreifende Konfigurationsdatei dar. Hier werden beispielsweise die Zugangsdaten für bestimmte Repository- oder Deployment-Server, die Einbindung von Plugins oder Bibliotheken-Repositories oder projektübergreifende Parameter eingestellt.

Profile sind ein weiterer Mechanismus, der durch entsprechende Einträge in der settings.xml (oder auch der pom.xml) umgesetzt werden kann. Für ein Profil können z. B. abweichende Parameter gesetzt, ein anderes Repository angegeben oder eine Filterdatei eingetragen werden (siehe Abbildung 5).

Durch die Übergabe des im Profil unterhalb des Tags activation definierten Property name wird das Profil beim Aufruf aktiviert. Auf diese Weise kann der Entwickler verschiedene Konfigurations- oder Filterdateien verwenden, ohne die Dateien selbst anpassen zu müssen. Das Beispielprofil könnte also durch die Übergabe des Parameters -DSkip_Test aktiviert werden und würde dazu führen, dass die Testphase des Build übersprungen wird.

Integration in IDE und Build Server

Für die wichtigsten Java-Entwicklungsumgebungen wie NetBeans, Eclipse oder IntelliJ existieren seit geraumer Zeit Plugins, die die Handhabung von Maven-Projekten erleichtern. Das Erstellen neuer Projekte, das Kompilieren der Quelldateien oder das Deployment des Projektes u. Ä. können einfach über die grafische Benutzeroberfläche angestoßen werden.

Das Maven Eclipse Plugin stellt z. B. verschiedene Goals bereit, damit man ein Maven-Projekt in Eclipse z. B. als WTP-Projekt importieren kann wobei gleichzeitig die Bibliotheken, die Dokumentation der Bibliotheken und deren Quellen heruntergeladen werden.

Unter NetBeans kann ein Maven-Projekt nach der Installation des Plugins direkt in der Entwicklungsumgebung durch Auswahl der pom.xml importiert werden. NetBeans legt dann die benötigten Projektdateien automatisch an und integriert alle notwendigen Bestandteile inklusive der Dokumentation in das neu erstellte NetBeans-Projekt.

Auch einige Build Server wie zum Beispiel Continuum unterstützen mittlerweile Maven2.

Hier reicht es, den Repository-Pfad der pom.xml anzugeben, um das Projekt in den Server zu integrieren. Danach können die Maven Tasks definiert werden, die ausgeführt werden sollen, um das Projekt zu erstellen.

Der Meister gegen die Ameise

Da Ant sicherlich immer noch das am weitesten verbreitete und bekannteste Build Managementpg Tool ist, muss Maven sich den Vergleich mit Ant gefallen lassen. Im Vordergrund steht hierbei die Frage, in welchen Fällen es sinnvoll ist, auf Maven zu setzen und in welchen Fällen Ant ausreicht oder die bessere Wahl ist. Die Unterschiede und die Vor- und Nachteile verdeutlicht Abbildung 6.

Ein derzeit noch häufig an Maven geäußerter Kritikpunkt ist die spärliche Dokumentation und Literatur. Hervorzuheben ist hierbei jedoch die Dokumentation der Apache Group sowie das kostenfreie Buch "Better Builds with Maven", das nicht nur die Einarbeitung erleichtert, sondern auch grundlegende Funktions- und Vorgehensweisen von Maven erläutert [2].

Fazit

Nachdem ORDIX Maven in mehreren großen Java-Projekten eingesetzt und auch große Projekte erfolgreich von Ant auf Maven umgestellt hat, lässt sich sagen, dass Maven mittlerweile ein ausgewachsenes Build Management Tool ist und die meisten der anfänglichen Schwierigkeiten und Einschränkungen überwunden hat. Zwar hakt es noch immer an der ein oder anderen Stelle und einige Mechanismen sind noch nicht ganz ausgereift, aber gerade bei großen Projekten kann die Verwendung von Maven eine deutliche Arbeitserleichterung bedeuten.

Eine Umstellung von Ant auf Maven kann sich jedoch, je nach Komplexität der alten Projektstruktur, relativ zeitaufwendig gestalten. Zudem kann das Auffinden und Einbinden von Plugins, mit denen zusätzliche Funktionalitäten eingebaut werden sollen, ein erheblicher Zeitfaktor sein.

Zusammenfassend lässt sich sagen, dass es bei größeren, neu zu erstellenden Projekten auf jeden Fall Sinn macht, Maven als Build Tool einzusetzen. Bei einer Umstellung von bestehenden Projekten sollte man allerdings genau abwägen, ob der Nutzen den Aufwand der Umstellung rechtfertigt.

Alexander Zeller (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen