Apache Maven Project

Aus THM-Wiki
Wechseln zu: Navigation, Suche
"Maven"

Maven ist ein Java Tool, welches Software-Entwickler bei der Entwicklung von Java-Projekten unterstützt. Es vereinfacht, vereinheitlicht und automatisiert Build-Prozesse und kümmert sich um Software-Abhängigkeiten. Sämtliche von Maven benötigten Informationen zu einem Projekt werden in einer zentralen XML-Datei gehalten, die auf dem sog. Project Object Model (POM) basiert. Maven wird von der Apache Software Foundation unter der Apache Software License, Version 2.0 gehostet und kann so bedenkenlos für kommerzielle Zwecke genutzt werden. Maven basiert auf einer Plugin-Architektur zu der bereits viele Plugins existieren. So gibt es beispielsweise Plugins, um automatisiert Javadoc zu einem Projekt zu erzeugen, JAR-Files zu erstellen oder ein Maven-Projekt in die Eclipse-IDE einzubinden.

Die Geschichte von Maven

Maven entstand vor ca. vier Jahren während der Arbeiten an dem Jakarta Alexandria-Projekt, aus welchem auch die Apache-Projekte Gump und Forrest entstanden. Nachdem es für ca. fünf Monate Teil von Alexandria war, wurde die Maven-Entwicklung anschließend in das Turbine-Projekt übernommen, wo man gerade damit beschäftigt war für die verschiedenen Turbine-Schichten (Persistence-Layer, Services-Layer und Web-Layer) separate Build-Prozesse einzuführen. Schnell empfand man es als müßig, verschiedene Builds zu pflegen, die nahezu identisch waren. Zu diesem Zeitpunkt gab es keine einfache Möglichkeit Ant-Builds zu vereinheitlichen und somit ergab sich für Maven damals folgende Zielsetzung:

  1. Eine zentrale Stelle zur Konfiguration für alles was ein Projekt und dessen Build betrifft.
  2. Eine Standard-Projekt-Verzeichnisstruktur - Man soll sich als Entwickler in neuen Projekten gleich zurechtfinden.

Des Weiteren stellte man fest, dass die benötigten JARs im CVS gehalten wurden, so dass oftmals viele Kopien einer Bibliothek in den verschiedenen Projekt-Ordnern lagen. Bei Updates musste dann jede dieser Kopien einzeln durch die neue Version ersetzt werden. Als Konsequenz daraus wurde Maven um die Möglichkeit ergänzt, im Project-Object-Model Projektabhängigkeiten zu deklarieren. Dazu wurde ein Repository eingeführt, in dem JARs an zentraler Stelle für alle Projekte zur Verfügung stehen. Für ein Internet-Repository, dass die wichtigsten Freeware-Bibliotheken enthalten sollte, wurde zunächst bei der Apache Group angefragt. Hier wäre es allerdings nicht möglich gewesen non-Apache Bibliotheken zu hosten, so dass GPL und LGPL Bibliotheken außen vor geblieben wären. Nach einigen Nachforschungen fand man Ibiblio, ein riesiges Archiv für allerlei Sachen, u.a. Freeware. Hier wird momentan das Maven Remote-Repository gehostet.

Maven im Überblick

Features

Als Hauptfeatures von Maven sind folgende zu nennen:

  • Einfaches, schnelles Erstellen und Einrichten von Projekten oder Modulen.
  • Entwickler, die neu zu einem Projekt dazustoßen, finden sich aufgrund der einheitlichen Maven-Projektstruktur schnell im Projekt zurecht.
  • Maven verwaltet Software-Abhängigkeiten (z.B. benötigte Bibliotheken) des Projekts an zentraler Stelle.
  • Es steht ein großes online-Repository von Bibliotheken und Metadaten zur Verfügung, welches direkt benutzt werden kann.
  • Viele große Open-Source-Projekte stellen aktuelle Snapshots ihrer Software auch über das Maven-Repository zur Verfügung.
  • Maven ist flexibel erweiterbar durch Plugins. Diese können in Java oder diversen Scriptsprachen auch selbst geschrieben werden.
  • Automatisches Generieren von Tests und Checkstyle-Reports unterstützt den Entwickler im Hinblick auf Qualitätssicherung.

Download und Setup

Maven wird von der Apache Group gehostet und ist dort über die Maven-Projektseite als Download erhältlich. Um Maven ausführen zu können wird ein Java Development Kit ab Version 1.4 benötigt. Maven selbst benötigt nur sehr wenig Festplattenspeicher. Allerdings wird bei Verwendung ein lokales Maven-Repository angelegt. Dorthin werden die JARs runtergeladen, die von den eigenen Projekten verwendet werden. Dieses ist im Schnitt 100MB groß, allerdings variiert die Größe je nach Verwendung.

Windows

Unter Windows entpackt man die Binaries zunächst in ein beliebiges Verzeichnis. Um Maven direkt in der Konsole verwenden zu können, ist es sinnvoll die Umgebungsvariable PATH anzupassen. Hierzu begibt man sich in die Systemeigenschaften von Windows und drückt unter dem Reiter "Erweitert" den Knopf "Umgebungsvariablen". Dort ergänzt man die Variable PATH um den Pfad zum bin-Verzeichnis der Maven-Installation. Außerdem sollte an dieser Stelle die Variable JAVA_HOME auf das Installationsverzeichnis der JDK-Installation gesetzt sein, um Maven benutzen zu können.

Linux, Solaris, Mac OS X

Unter o.g. Betriebssystemen entpackt man die Binaries ebenfalls in ein beliebiges Verzeichnis, z.B. /usr/local/maven-2.0.4 um Maven für mehrere Benutzer zu installieren. Auch hier bietet sich an den Pfad zum bin-Verzeichnis der Maven-Installation der PATH-Variablen hinzuzufügen, beispielsweise über die export-Anweisung. Um Maven benutzen zu können, muß auch unter Unix-basierten Systemen die Umgebungsvariable JAVA_HOME auf die JDK-Installation verweisen.

Konfiguration von Maven

Maven wird über verschiedene XML-Dateien konfiguriert. Projektbezogene Einstellungen werden im sog. Project-Object-Model gehalten, während benutzerdefinierte Einstellungen in der Datei settings.xml vorgenommen werden. Diese befindet sich im Verzeichnis ~/.m2, welches von Maven beim ersten Start automatisch im sog. Home-Verzeichnis des Benutzers angelegt wird. Dort kann beispielsweise auch festgelegt werden, welches Verzeichnis Maven als lokales Repository verwenden soll. Eine vollständige Beschreibung der Konfigurationsdatei findet man unter maven.apache.org/maven-settings/settings.html.

Das Maven-Repository

Das Repository von Maven enthält alle, von Maven-Projekten benötigten, Bibliotheken und Abhängigkeiten. Man unterscheidet strikt zwei Typen: Remote- und Local-Repositories.

Das Local-Repository ist ein lokales Verzeichnis auf dem Rechner des Entwicklers, welches gerade benötigte JARs enthält. Wurden Bibliotheken einmal vom Remote-Repository heruntergeladen, verbleiben sie vorerst lokal auf der Festplatte, um den Traffic bei weiterer Verwendung gering zu halten. Remote-Repositories besitzen die gleiche Verzeichnisstruktur. Der Zugriff auf das Remote-Repository erfolgt über Protokolle wie HTTP oder via File URL. Es liegt in der Regel auf einem entfernten System, was jedoch nicht zwingend notwendig ist. Das Standard-Maven-Repository wird von ibiblio.org gehostet, allerdings verwenden viele Firmen gerne ein internes - eigenes - Remote-Repository, um Entwicklern firmenintern private Artefakte zur Verfügung zu stellen.

Warum keine JARs ins CVS?

Dadurch, dass man seinen Projekten mit Hilfe von Maven benötigte JARs lokal und redundanzfrei zur Verfügung stellen kann, wird weniger Speicherplatz auf dem CVS-Server benötigt. Der Checkout-Vorgang geht wesentlich schneller von statten. Davon abgesehen brauchen JARs eigentlich keine Versionierung durch CVS, da sie sich nur selten ändern. Wenn sich ihre Version ändert hat dies in der Regel auch Einfluss auf den Dateinamen. Für JARs ist ein CVS also überflüssig.

Repositories verwenden

Normalerweise kann man das Maven-Repository, ohne irgendwelche Einstellungen zu tätigen, direkt verwenden.

Baut man ein Maven-Projekt, das von einer Bibliothek abhängig ist, versucht Maven diese automatisch aus dem Remote-Repository herunterzuladen und im lokalen-Repository zu speichern. Ist die Bibliothek bereits im lokalen-Repository vorhanden, wird die lokale Version verwendet. Eine Ausnahme besteht für Abhängigkeiten die mit der Versionsnummer SNAPSHOT versehen sind. Für diese wird immer online nachgesehen, ob eine aktuellere Variante als die lokale vorhanden ist.

Ein alternatives Remote-Repository verwenden

Möchte man ein alternatives Remote-Repository verwenden, setzt man in der Einstellungs-Datei (~/.m2/settings.xml) das Repository auf den gewünschten Pfad.

Hier der zugehörige Auszug aus der settings.xml Datei:

<repositories>
	<repository>
		<release>
			<enabled/>
			<updatePolicy/>
			<checksumPolicy/>
		</release>
		<snapshot>
			<enabled/>
			<updatePolicy/>
			<checksumPolicy/>
		</snapshot>
		<id/>
		<name/>
		<url/>
		<layout/>
	</repository>
</repositories>

Plugins

Maven bietet jede Menge Plugins für die alltägliche Arbeit und wird bereits mit einigen davon ausgeliefert. Wer ins Detail gehen möchte, dem sei die Plugin-Seite unter maven.apache.org/plugins ans Herz gelegt, dort sind sämtliche Plugins mit all ihren Facetten dokumentiert. Hier ein paar grundlegende:

  • archetype dient zum Erzeugen eines neuen Projekts nach einem vorhandenen Archetypen. Es existiert beispielsweise standardmässig ein Archetyp für Web-Applikationen.
  • compile wird verwendet um die Java-Quellen zu kompilieren
  • install baut ein Projekt und stellt dieses im lokalen Repository als eigene Bibliothek anderen Maven-Projekten zur Verfügung.
  • deploy dient dazu, ein Projekt als Artefakt im Remote-Repository einzustellen - Schreibrechte vorausgesetzt.
  • jar baut das Projekt als *.jar-File
  • war baut das Projekt als *.war-File (zum Deployment auf einen Application Server)
  • javadoc erzeugt eine Javadoc-Dokumentation des Maven-Projekts
  • eclipse generiert ein Eclipse-Project-File für ein Maven-Projekt, um dieses in der Eclipse-IDE verwenden zu können. Hierbei werden unter anderem die Libraries aus dem Maven-Repository auf dem Buildpath gesetzt, so dass dies nicht mehr in Eclipse von Hand gemacht werden muss.
  • site erstellt eine Projekt-Homepage zu einem Maven-Projekt. Die Seite des Apache Maven-Projekts wurde beispielsweise via Maven generiert.

Maven und Eclipse

Da heutzutage angestrebt wird, alles direkt aus einer Integrierten Entwicklungsumgebung heraus zu steuern, sind Maven-Plugins für IDEs wie Eclipse oder Netbeans natürlich gerne gesehen. Mevenide und m2eclipse sollen hier kurz vorgestellt werden, beide sind als Freeware über www.codehaus.org erhältlich.

Mevenide (Maven 1.x)

Ziel von Mevenide ist es, Maven (Version 1.x) in die gängigen IDEs (Eclipse, Netbeans, JBuilder, IntelliJ) zu integrieren. Aus der Entwicklungsumgebung heraus lassen sich mit Mevenide die Laufzeiteigenschaften von Maven einstellen, das POM editieren und Maven starten. Darüber hinaus unterstützt Mevenide die Entwicklung von Maven-Projekten mit diversen Wizards. Für die Verwendung innerhalb von Eclipse müssen folgende Anforderungen erfüllt sein:

  • Eclipse 3.0
  • Maven 1.0
  • J2SE 1.4.2

Die Installation erfolg über den Update-Mechanismus von Eclipse, dieser ist unter Help > Software Updates > Find and Install... zu finden. Hier muß eine Updateseite angelegt werden, die auf folgende URL verweist:

http://mevenide.codehaus.org/release/eclipse/update/site.xml

Konfiguration von Mevenide

Mevenide lässt sich über die Einstellungen von Eclipse konfigurieren (Window > Preferences > Maven).

Die Konfigurationsmaske von Mevenide unter Eclipse

Eclipse-Projekte mit Mevenide

Ein bestehendes Eclipse-Projekt kann über das Mevenide-Kontextmenu als Maven-Projekt aktiviert werden. Hier wird zunächst ein Project Object Model für das Projekt angelegt. Unter Window > Show View > others... Können spezielle Maven-Views geladen werden.

Ein Eclipse-Projekt wird zum Maven-Eclipse-Projekt

m2eclipse (Maven 2.x)

m2Eclipse wird von der Firma Megere unter der Apache Software License Version 2.0 entwickelt. Es zielt darauf ab Maven ab der Version 2.x in Eclipse zu integrieren. Da es momentan der Eclipse Foundation vorgelegt wurde und evtl. in Zukunft als Projekt der Eclipse Foundation anerkannt wird, kann es sein, dass sich die Lizenz ändert.

Auch m2eclipse wird über den Update-Mechanismus von Eclipse installiert. Hierzu muss folgende Update-Seite angelegt werden:

http://m2eclipse.codehaus.org/

Unter [1] findet man ein Demo zur Installation von m2eclipse. Zur Verwendung des Plugins findet man ebenfalls eine Demonstration unter [2].

Projekte mit Maven

Im Folgenden soll Schritt für Schritt die Verwendung von Maven anhand eines Beispiel-Projekts erläutert werden. Beim ersten Programmaufruf von Maven werden einige Plugins und Bibliotheken heruntergeladen, weshalb anfangs mit einer gewissen Wartezeit zu rechnen ist.

Ein Projekt anlegen

Zum Erzeugen eines ersten Projekts verwenden wir den Archetype-Mechanismus von Maven. Ein Archetype ist eine Art Projekt-Schablone für bestimmte Arten von Projekten (wie z.B. Web-Applikationen). Das archetype-Plugin von Maven erzeugt uns mit folgendem Befehl ein neues Maven-Projekt:

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app

Der Befehl erzeugt uns ein Verzeichnis namens my-app. Dort wurde von Maven zunächst ein Standart-Projektdeskriptor (die Datei pom.xml) generiert.

Kompilieren und Testen

Wenn wir unsere Java-Quellen zunächst kompilieren möchten, bewerkstelligen wir dies mit dem compile-Aufruf:

mvn compile

Hierbei werden die class-Dateien in das Standard-Verzeichnis /target/classes unserer Anwendung geschrieben. Möchten wir unseren Code nun testen, kompilieren wir die Tests und führen diese mit folgendem Befehl aus:

mvn test

Sollen die Tests lediglich kompiliert werden, wird Maven nicht mit test, sondern mit test-compile aufgerufen. Beide Aufrufe können auch zusammen ausgeführt werden:

mvn compile test

Abhängigkeiten verwalten

Ein grundlegendes Feature von Maven ist die Verwaltung von Projektabhängigkeiten. In der zentralen Projekt-Datei, werden die Abhängigkeiten unseres Maven-Projekts festgelegt. Verwendet unser Projekt beispielsweise die Tomahawk-Bibliothek des Apache myFaces-Projekts, würden wir dies folgendermaßen in pom.xml definieren:

<dependencies>
	...	
	<dependency>
		<groupId>myfaces</groupId>
		<artifactId>tomahawk</artifactId>
		<version>1.1.1</version>
	</dependency>	
	...
</dependencies>  

Wenn dieser Eintrag in der pom.xml vermerkt ist, versucht Maven beim Bauen des Projekts die Datei tomahawk-1.1.1.jar aus dem Remote-Repository zu laden, es sei denn, sie liegt schon im lokalen Repository. Das Maven-Plugin eclipse würde die Tomahawk-Bibliothek dann automatisch dem Build-Path des Eclipse-Projekts hinzufügen.

Resource-Files

Oftmals verwendet man in einem Java-Projekt sog. Resource-Bundles, bzw. *.properties-Dateien. Diese dienen dazu, Anwendungen leichter an lokale Gegebenheiten anzupassen. Diese Properties werden zur Laufzeit vom ClassLoader bereitgestellt, weshalb diese beim Build des Projekts ebenfalls berücksichtigt werden müssen. Im Build-Abschnitt der pom.xml können verschiedene Pfade zu Resourcen angegeben werden:

<build>
  ...
  <sourceDirectory>src/main/java</sourceDirectory>    
  <testSourceDirectory>src/test/java</testSourceDirectory>
  ...
  <resources>
    <resource>
      <directory>src/main/resources</directory>
    </resource>
  </resources>
  <testResources>
    <testResource>
      <directory>src/test/resources</directory>
        <includes>
          <include>*.properties</include>
        </includes>
    </testResource>
  </testResources>
</build>	

Dokumentation

Maven bietet ein Plugin um automatisch eine Projektseite mit Javadoc-Api zu erstellen. Zunächst muss hierfür folgende Verzeichnisstruktur existieren:

+- src/
   +- site/
      +- apt/
      |  +- index.apt
      |
      +- xdoc/
      |  +- other.xml
      |
      +- fml/
      |  +- general.fml
      |  +- faq.fml
      |
      +- site.xml

Anschließend kann eine Standard-Seite mit dem site-Befehl erzeugt werden.

In der Datei site.xml kann die Seitenerstellung konfiguriert werden. Für eine vollständige Dokumentation sei an dieser Stelle auf die Site Plugin Dokumentation verwiesen.

Archetypen

Ein Archetype ist eine Art Schablone für die Erstellung von sich ähnelnden Maven-Projekten. Archetypes werden auch als JARs verpackt im Maven-Repository gespeichert. Möchte man beispielsweise in Zukunft mehrere Webanwendungs-Projekte erstellen, könnte man hierfür einen Archetype anlegen, mit dem sich ein solches Projekt unter Angabe weniger Parameter aufsetzen lässt.

Archetypen erstellen

Standardmässig wird Maven mit einem einzigen Archetype geliefert (webapp), man kann natürlich beliebig viele eigene Archetypen anlegen. Hierzu setzt man ein Maven-Projekt mit etwa folgender Verzeichnisstruktur auf:

archetype
|-- pom.xml
`-- src
    `-- main
        `-- resources
            |-- META-INF
            |   `-- archetype.xml
            `-- archetype-resources
                |-- pom.xml
                `-- src
                    |-- main
                    |   `-- java
                    |       `-- App.java
                    `-- test
                        `-- java
                            `-- AppTest.java

In der Datei archetype.xml, dem sogenannten Archetype-Descriptor, werden alle Dateien deklariert, die nach der Ersetellung eines Projekts dieses Archetypes vorhanden sein sollen. Diese sieht für unser Quick-Start Projekt etwa so aus:

<archetype>
  <id>quickstart</id>
  <sources>
    <source>src/main/java/App.java</source>
  </sources>
  <testSources>
    <source>src/test/java/AppTest.java</source>
  </testSources>
</archetype>

Prototypen dieser Dateien liegen im Verzeichnis src/main/resources/archetype-resources. Zusätzlich wird noch ein Prototyp-pom.xml-File für die Anwendung erzeugt, die das Standard-POM für Projekte von diesem Archetype darstellt. Das POM des Archetype Projekts selbst sieht etwa so aus:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>my.groupId</groupId>
  <artifactId>my-archetype-id</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>maven-plugin</packaging>
</project>	

Möchten wir unseren Archetype nun als JAR ins Repository installieren, verwenden wir das install-Plugin:

mvn install

Um den Archetype zu verwenden, rufen wir wie gewohnt Folgendes auf:

mvn archetype:create -DarchetypeGroupId=<archetype-groupId> -DarchetypeArtifactId=<archetype-artifactId> 
    -DarchetypeVersion=<archetype-version> -DgroupId=<my.groupid> -DartifactId=<my-artifactId>

Dotplot via Maven

An dieser Stelle soll das DotPlot-Projekt beispielhaft mit Maven gebaut werden. Leider bin ich aufgrund technischer Probleme seitens Sourceforge.net hiermit etwas in Verzug geraten.

Das prinzipielle Vorgehen ist wie folgt. Zunächst muß für das DotPlot-Projekt ein Project Object Model (eine pom.xml-Datei) angelegt werden. Hier werden zunächst allgemeine Angaben zum Projekt gemacht:

<?xml version="1.0" encoding="UTF-8"?>
<project>
	<modelVersion>4.0.0</modelVersion>
	<groupId>dotplot</groupId>
	<artifactId>org.dotplot.plugin</artifactId>
	<version>2.1.1-SNAPSHOT</version>
	<description>The DotPlot Project managed by Maven 2</description>
        <developers>
		<developer>
			<name>Hans Mustermann</name>
			<email>abc@efg.com</email>
			<organization>FH-Giessen</organization>
			<organizationUrl>http://www.fh-giessen.de</organizationUrl>
		</developer>
	</developers>
        ...

Anschließend wird der Buildvorgang konfiguriert. Hierzu werden die Pfade zu den Java-Quellen, den Test-Klassen und den benötigten Resourcen angegeben. In einem zweiten Schritt werden die verwendeten Plugins konfiguriert, so dass das Compiler-Plugin beispielsweise auf dem Source-Level für Java 1.5 arbeitet.

        ...
	<build>
		<sourceDirectory>src</sourceDirectory>
		<testSourceDirectory>tests</testSourceDirectory>
		<outputDirectory>target/classes</outputDirectory>
		<testOutputDirectory>target/test-classes</testOutputDirectory>
		<resources>
			<resource>
				<directory>icons</directory>
			</resource>
			<resource>
				<directory>ressources</directory>
			</resource>
			<resource>
				<directory>lib</directory>
			</resource>
			<resource>
				<directory>plugins</directory>
			</resource>
		</resources>
		<directory>target</directory>
		<finalName>${artifactId}-${version}</finalName>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.5</source>
					<target>1.5</target>
				</configuration>
			</plugin>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-jar-plugin</artifactId>
				<configuration>
					<archive>
						<manifest>
							<mainClass>
								org.dotplot.plugin.DotplotApplication
							</mainClass>
							<packageName>
								org.dotplot.eclipse
							</packageName>
							<manifestFile>/META-INF</manifestFile>
							<addClasspath>true</addClasspath>
							<addExtensions />
							<classpathPrefix />
						</manifest>
						<manifestEntries>
							<mode>development</mode>
							<url>${pom.url}</url>
						</manifestEntries>
					</archive>
				</configuration>
			</plugin>
		</plugins>
	</build>
        ...

Zum Abschluß werden die Projektabhängigkeiten des DotPlot-Projekts angegeben. Da einige dieser Bibliotheken nicht im offiziellen ibiblio-Maven-Repository sind, müssen sie zunächst runtergeladen und von Hand über das install-file Goal im lokalen Repository installiert werden. Beispielsweise so:

 mvn install:install-file -DgroupId=mygroup -DartifactId=myartifact -Dversion=x.x.x -Dfile=myartifact-x.x.x.jar -Dpackaging=jar

In der pom.xml werden sie wie folgt angegeben:

        ... 
        <dependencies>
		<dependency>
			<groupId>javax.activation</groupId>
			<artifactId>activation</artifactId>
			<version>1.1</version>
		</dependency>
		<dependency>
			<groupId>clibwrapper</groupId>
			<artifactId>clibwrapper</artifactId>
			<version>1.1</version>
		</dependency>
		<dependency>
			<groupId>iText</groupId>
			<artifactId>iText</artifactId>
			<version>1.1</version>
		</dependency>
		<dependency>
			<groupId>jai</groupId>
			<artifactId>codec</artifactId>
			<version>1.1</version>
		</dependency>
		<dependency>
			<groupId>jai</groupId>
			<artifactId>core</artifactId>
			<version>1.1</version>
		</dependency>
		<dependency>
			<groupId>jai</groupId>
			<artifactId>imageio</artifactId>
			<version>1.1</version>
		</dependency>
		
                    ...

		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>3.8.1</version>
		</dependency>
		<dependency>
			<groupId>log4j</groupId>
			<artifactId>log4j</artifactId>
			<version>1.2.9</version>

		</dependency>
	</dependencies>
</project>

Mit Hilfe von Maven können wir das Projekt nun kompilieren. Mit den oben genannten Plugins können wir auch Tests fahren, Checkstyle-Reports erzeugen, Doku generieren lassen, etc.

Fazit

Maven ist ein hilfreiches Tool, dass Java-Entwicklern bei der Entwicklung größerer Projekte entgegenkommt. Auf der Projektseite findet man gute Dokumentation mit vielen hilfreichen Beispielen. Nichtsdestotrotz braucht man eine gewisse Zeit sich an die Arbeitsweise von Maven zu gewöhnen. Ist diese Hürde erst einmal genommen, findet man sich in anderen Maven-Projekten aufgrund der einheitlichen Projektstruktur und der zentralen Projekt-Konfiguration in der Regel sofort zurecht.

Schwierigkeiten gibt es mit Maven dann, wenn man versucht, ein bestehendes Projekt auf Maven zu portieren, dessen Build von einer anderen Software (z. B. Eclipse-Plugins via Eclipse) verwaltet wird. Hier stellt sich dann die Frage, ob der Zeitaufwand lohnt, diesen Prozess mit Maven nachzuahmen.

Literatur und Quellen