Grundlagen des Buildmanagement

Grundlagen des BuildmanagementTools Apache Maven
Seminararbeit
im Studiengang
Scientific Programming
vorgelegt von
Sinan Böcker
Matr.-Nr.: 836951
am 15. Dezember 2011
an der Fachhochschule Aachen
Erstprüfer:
Zweitprüfer:
Prof. Dr. rer. nat. Bodo Kraft
Dipl.-Inf. Arne Rache
Abstract
1
Abstract
Die Folgende Seminararbeit „Grundlagen des Buildmanagement-Tools Apache Maven“ gibt
einen Einblick in die Automatisierung des Build-Prozesses in der Softwareerstellung. Maven soll
hierbei dem Entwickler möglichst viele Aufgaben abnehmen und diese automatisieren, wie
beispielsweise das Erstellen, das Testen oder die Distribution der Software. Besonders bei
großen Software-Projekten nimmt ein derartiges Automatisierungstool den Entwicklern viel
Arbeit ab. In dieser Seminararbeit wird auf die Motivation der Nutzung, die Funktionsweise und
eine Beispielkonfiguration von Maven eingegangen. Des Weiteren wird Maven mit dem
populären Buildmanagement-Tool Apache Ant verglichen.
Inhaltsverzeichnis
2
Inhaltsverzeichnis
Abstract ............................................................................................................................................ 1
Inhaltsverzeichnis ............................................................................................................................. 2
1.
2.
3.
4.
5.
Einleitung .................................................................................................................................. 3
1.1
Was ist Maven? ................................................................................................................. 3
1.2
Motivation für Buildmanagement ..................................................................................... 3
1.3
Maven Grundlagen ............................................................................................................ 4
Funktionsweise ......................................................................................................................... 7
2.1
Lifecycles ............................................................................................................................ 7
2.2
Plugins ................................................................................................................................ 9
2.3
POM ................................................................................................................................. 12
2.4
Repositories ..................................................................................................................... 14
Konfiguration .......................................................................................................................... 15
3.1
Anlegen eines Projektes .................................................................................................. 15
3.2
Erstellen des Projektes .................................................................................................... 16
3.3
Hinzufügen einer Abhängigkeit ....................................................................................... 16
3.4
Weitere Möglichkeiten .................................................................................................... 16
Vergleich mit Apache Ant ....................................................................................................... 18
4.1
Ant Grundlagen................................................................................................................ 18
4.2
Vergleich mit Maven........................................................................................................ 19
Fazit ......................................................................................................................................... 21
5.1
Zusammenfassung ........................................................................................................... 21
5.2
Ausblick ............................................................................................................................ 21
6.
Literaturverzeichnis ................................................................................................................ 23
7.
Eidesstattliche Erklärung......................................................................................................... 24
Einleitung
3
1. Einleitung
Die vorliegende Seminararbeit behandelt das Buildmanagement-Tool Maven. Sie soll dem Leser
eine Einführung in Maven bieten und diesen motivieren, es in Projekten zu nutzen. Das Thema
„Grundlagen des Buildmanagement-Tools Maven“ wurde gewählt, da es in der Firma
TravelTainment bei den meisten Projekten genutzt wird. Maven ist sehr verbreitet unter JavaEntwicklern.
1.1 Was ist Maven?
Maven ist ein Buildmanagement-Tool, welches dem Entwickler bei Vorverarbeitung,
Kompilierung, Testen und Verteilung von Software behilflich ist. Neben den BuildFunktionalitäten bietet Maven viele Projektrelevante Funktionen, wie das Erstellen von
Berichten bzw. Reports oder das Generieren von Webseiten.
1.2 Motivation für Buildmanagement
Eine der Herausforderungen bei großen Software-Projekten ist es, dem Entwickler so viel Zeit
wie möglich zu geben, in der er produktiv am Projekt arbeiten kann. Dabei kann es dazu
kommen, dass er von manuellen Updates, Integrierungen und Konfigurationen von Bibliotheken
abgelenkt wird. Diese Ablenkungen entfallen mit Maven größtenteils durch verschiedenste
Automatisierungen. Zusätzlich ist es mit Maven möglich neue Entwickler schnell produktiv in die
Arbeiten an dem Projekt zu integrieren. Normalerweise dauert dies oft mehrere Stunden oder
sogar Tage. Der Entwickler muss eingearbeitet werden und alle benötigten Resourcen, d.h.
benötigte Pakete und Bibliotheken müssen beschafft werden. In der Regel muss ein Kollege dem
Neuling helfen, wodurch dieser nicht produktiv arbeiten kann. Der Zeitaufwand den neuen
Entwickler in Maven einzuarbeiten und dieses zu Konfigurieren ist meist um ein Vielfaches
geringer als das manuelle Vorgehen.
Neben der einfach zu erlernbaren Struktur und den vielen Automatisierungen der
Buildprozesse, ist aber auch die Erweiterbarkeit von Maven wichtig. So lassen sich
Einleitung
4
beispielsweise mit Hilfe der Plugins automatisiert JavaDocs1 oder Fehler-Reports erstellen, es
muss also kein externes Tool dafür genutzt werden.
Früher gab es viele Diskussionen um das richtige Vorgehen und genauso viele Ansätze für BuildKonzepte. Im Grunde waren diese Ansätze aber ineffizient, da keine Konventionen genutzt
wurden. Im Laufe der Zeit wurden jedoch beispielsweise mit Maven Konventionen geschaffen.
Die Bedeutung der Konventionen wird im nächsten Kapitel (1.3) verdeutlicht.
Der Entwickler soll bei möglichst vielen Aufgaben unterstützt werden, welche im Idealfall sogar
automatisiert werden. Maven lädt alle benötigten Pakete bei Bedarf aus einem zentralen
Repository auf das lokale Repository des Entwicklers herunter, wodurch jeder Entwickler
automatisch Zugriff auf alle benötigten und aktuellsten Konfigurationen und Bibliotheken hat.
Eine genauere Erklärung von Repositories findet sich in Kapitel 2.4.
1.3 Maven Grundlagen
Der Grundsatz von Maven ist „Konvention vor Konfiguration“. Das heißt, dass ein großer Teil der
Strukturen vorgegeben ist. Der Entwickler muss nur die Teile des Projektes konfigurieren die
nicht von Maven vordefiniert sind. Im Falle von Maven soll der Entwickler primär am
eigentlichen Projektcode bzw. dem Inhalt des Projektes arbeiten, und möglichst wenig an
Konfigurationen, Strukturen, oder Abläufen, die zur Kompilierung oder Veröffentlichung nötig
sind. Die Konventionen äußern sich zum Beispiel in der Trennung des Projektcodes, dem Code
der Unit-Tests und jeweils der Ressourcen. Diese Daten liegen immer in fest definierten
Verzeichnissen. Obwohl es nicht ratsam ist vorgegebene Strukturen anzupassen, lässt Maven
den Entwickler die meisten Vorgaben an die eigenen Bedürfnisse anpassen. Es ist beispielsweise
möglich Projektverzeichnise anzupassen, oder den Ordnernamen zu ändern. Wenn keine
manuellen Anpassungen vorgenommen wurden, hat jedes mit Maven erstellte Projekt die
gleiche Verzeichnisstruktur. Dies macht die Projekte für erfahrene Maven-Entwickler sehr
übersichtlich. Zusätzlich können dadurch Funktionen auf verschiedene Projekte angewendet
werden, ohne Anpassungen vornehmen zu müssen. Dies bildet auch die Basis für das PluginSystem Mavens bildet.
1
Automatische Softwaredokumentation des Java-Sourcecodes
Einleitung
5
simple/
simple/pom.xml
/src/
/src/main/
/main/java
/src/test/
/test/java
Beispiel 1 - Die automatisch erstellte Verzeichnisstruktur
Um Abhängigkeiten und Projektbeziehungen zu konfigurieren, nutzt Maven ein genau
definiertes Projektmodell (POM – Project Object Model). Dieses wird in der Datei pom.xml
gespeichert, die im Projektverzeichnis liegt.
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Beispiel 2 - Ein minimales POM
Das sogenannte Super-POM liefert Standard-Konfigurationen für Verzeichnisse und Plugins. Alle
anderen POMs sind von der Super-POM abgeleitet, und erben damit alle darin definierten
Eigenschaften. Maven verwendet ein lokales Verzeichnis, welches „lokales Repository“ genannt
wird. In diesem werden Bibliotheken abgelegt, die zum Erstellen eines Builds2 benötigt werden.
Werden weitere Bibliotheken oder neue Versionen von Bibliotheken benötigt, werden diese
automatisch in das Repository kopiert bzw. aktualisiert. Dadurch entfällt die Notwendigkeit
einer manuellen Verwaltung der Bibliotheken.
2
Erstellung eines Programmes aus dem Sourcecode
Einleitung
6
Maven geht von immer wiederkehrenden Aufgaben aus. Daher werden fest definierte Lifecycles
(Lebenszyklen) genutzt. Der Standard- Lifecycle ist der Build-Lifecycle, der die feste Reihenfolge
enthält, die zur Erstellung eines Builds nötig ist. Da die Reihenfolge der Phasen von Maven
feststeht, ist außerdem keine Analyse bzw. Erstellung von Build-Skripten nötig. Auf Lifecycles
wird in Kapitel 2.2 genauer eingegangen.
Maven basiert auf Java und kann insbesondere Java-Projekte (auch C#, Ruby, Scala usw.)
standardisiert erstellen und verwalten.
Das vollständige Super-POM kann auf der Maven-Homepage gefunden werden3.
3
http://maven.apache.org/ - 14.12.2011
Funktionsweise
7
2. Funktionsweise
Maven hat ein fest definiertes Modell eines Projekts. Diese Modell ermöglicht:

Abhängigkeits-Verwaltung
Die Indentifizierbarkeit eines Projektes mittels Gruppenkennung, Artefaktkennung4
und Version ermöglicht eine Abhängigkeitsverwaltung.

Repositories
Die in den POMs angegebenen Abhängigkeiten machen es möglich, Sammlungen von
Bibliotheken zu erstellen und diese den Nutzern zur Verfügung zu stellen. Dabei gibt es
Remote-Repositories, welche Bibliotheken für den bzw. die Nutzer zur Verfügung
stellt, sowie lokale Repositories, das Repository des jeweiligen Entwicklers. Das lokale
Repository gleicht sich automatisch mit dem Remote-Repository ab. (evtl. Verweis auf
Lifecycles, bzw. deren späterer Erläuterung)

Wiederverwendung
Ein einzelnes Plugin kann für verschiedene Zwecke genutzt werden. Siehe Kapitel 2.2.

Integration
Durch das genau definierte Modell können verschiedene Werkzeuge bzw. IDEs auf die
gleichen Projektinformtionen zugreifen. Obwohl die IDEs unterschiedlich aufgebaut
sind, lassen sich die Projektinformationen durch das Modell leicht auslesen.
2.1 Lifecycles
Die Abarbeitung von bestimmten Arbeitsschritten, beispielsweise in Form von Plugins, in einer
fest definierten Reihenfolge, nennt sich Lifecycle(Lebenszyklus). Maven basiert auf diesem
Konzept der Lebenszyklen. Ein Lifecycle enthält alle Phasen die nötig für den Build-Vorgang sind.
Ebenfalls definiert im Lifecycle ist die Distribution. Für den Entwickler bedeutet das, dass er sich
keine breite Auswahl von Befehlen merken muss, sondern nur einige wenige. Die POM des
Projektes sorgt für das Ergebnis.
Standartmäßig enthält Maven drei Lifecycles: default, clean und site. Clean beseitigt alles was
für das Projekt nicht direkt benötigt wird, beispielsweise die Kompilierten-Dateien des
4
Artefakt: Objekt in der Softwareentwicklung
Funktionsweise
8
vorherigen Build-Vorgangs. Site ist zuständig für die Projektdokumentation. Auf den DefaultLifecycle wird im Folgenden genauer eingegangen.
Der Default-Lifecycle enthält folgende Phasen:

Validate
Überprüft das Projekt auf Fehler und stellt sicher dass alle benötigten Informationen
vorhanden sind.

Compile
Kompiliert den Sourcecode des Projekts.

Test
Testet den kompilierten Sourcecode, mit einem passenden Unit-Test-Framework
(siehe „Surefire“ Kapitel 2.2). Für diese Tests muss das Projekt in der Regel nicht
gepackt und deployed sein.

Package
Packt den kompilierten Sourcecode in das gewünschte Format. Ein Beispiel dafür wäre
das Jar-Format.

Integration-test
Deployment in eine Testumgebung.

Verify
Testet ob das Paket valide ist und ob es den Qualitäts-Kriterien entspricht.

Install
Installiert das Paket im lokalen Repository, und kann dann lokal in anderen Proekten
als Dependency genutzt werden.

Deploy
Kopiert das fertige Paket in das Remote-Repository, damit es für andere Entwickler
und Projekte zur Verfügung steht.
Build-Phasen eines Lifecycles werden sequentiell ausgeführt, die Reihenfolge untereinander ist
nicht veränderbar. Wird eine Phase aufgerufen, werden automatisch alle vorher nötigen Phasen
durchlaufen. Jede der Phasen besteht wiederum aus so genannten Goals (Deutsch: „Ziel“). Ein
Funktionsweise
9
Goal hat eine ähnliche Aufgabe wie eine Phase, beide definieren eine bestimmte Aufgabe. Ein
Goal führt jedoch eine bestimmte Funktionalität eines Plugins aus.
Um also das Projekt in das Remote-Repository zu kopieren muss nur der Deploy-Befehl
aufgerufen werden, womit automatisch alle anderen benötigten Schritte durchgeführt würden.
Will der Nutzer beispielsweise seine Unit-Tests ausführen, müsste er den Test-Befehl aufrufen.
Damit würden als erstes der Sourcecode validiert werden, dann der Sourcecode kompiliert
werden und als letztes die Unit-Tests aufgerufen werden.
2.2 Plugins
Das Grundgerüst von Maven hat wenige Funktionen. Maven wurde so konzipiert, dass die
meisten Funktionen von Plugins geliefert werden. Die Grundfunktionen beinhalten etwa das
Parsen von XML-Dateien, Plugin-Verwaltung und den Default-Lifecycle. Das heißt dass die
Hauptverantwortung auf Plugins fällt. Zum Beispiel besitzt Maven keine Möglichkeit zum
Ausführen von JUnit-Tests. Diese werden von einem Plugin durchgeführt, welches für die TestPhase zuständig ist. Auch andere wichtige Funktionen wie das Kompilieren des Projektes sind
nicht Bestandteil der Grundfunktionen von Maven. Jede Phase kann von einem Plugin „ersetzt“
werden.
Maven hat also verschiedene Aufgaben als Plugins ausgelagert. Dies hat den Vorteil, dass
einzelne Plugins mit bestimmten Aufgaben weitaus leichter zu Warten und Einzusetzen sind, als
große Bibliotheken. Der Nutzer muss nichts tun um Updates der Plugins zu erhalten, da dies von
Maven geregelt wird. Das heißt gleichzeitig auch dass der Nutzer in seinem Projekt so gut wie
keine Anpassungen am Projektcode machen muss um neuen Code zu unterstützen,
vorrausgesetzt die Abwärtskompatibilität des Plugins ist erhalten geblieben. Die einzige
Benötigte Anpassung ist die Versionsnummer des jeweiligen Plugins in der Projekt-POM. Wird in
der POM eine neue Version eingetragen, wird diese automatisch ins lokale Repository
heruntergeladen und benutzt.
Ein bekanntes Beispiel für ein Plugin ist das Surefire-Plugin, welches für die Auführung von UnitTests zuständig ist. Es ermöglicht unter anderem JUnit3- und JUnit4-Tests, sowie TestNG-Tests.
Funktionsweise
10
Hierbei wurde sehr auf Abwärtskompatibilität geachtet, damit beispielsweise Nutzer von JUnit3Tests diese auch weiterhin ohne Anpassungen nach einem Update weiternutzen können.
Durch dieses Plugin-Konzept ist es leicht möglich Maven um weitere Funktionalitäten zu
erweitern.
Nachfolgend einige populäre Maven-Plugins:

Clean
Das „Clean“-Plugin hat die Aufgabe, die Dateien und Verzeichnisse, die Maven
während dem Builden generiert, zu löschen. Das „Clean“-Plugin ist an die Clean-Phase
gebunden, kann jedoch auch manuell aufgerufen werden.

Compiler
Das „Compiler“-Plugin ist zuständig für die Kompilierung des Quellcodes. Der
Standardcompiler ist dabei javac, es können allerdings auch beispielsweise die
Compiler von .NET oder C# genutzt werden.

Deploy
Das “Deploy” –Plugin wird hauptsächlich während der Deploy-Phase (siehe Kapitel 2.1)
genutzt. Es ist dafür zuständig, die Artefakte des Entwicklers einem Remote-Repository
(siehe Kapitel 2.4) hinzuzufügen, um es anderen Entwicklern zur Verfügung zu stellen.

Eclipse
Das “Eclipse”-Plugin ermöglicht es, aus dem Maven-Projekt ein Eclipse-Projekt zu
generieren.

Install
Das “Install”-Plugin fügt Artefakte aus dem Remote-Repository (siehe Kapitel 2.4) zum
lokalen Repository hinzu. Dazu nutzt es die Informationen aus der Projekt-POM.

Surefire
Das “Surefire”-Plugin führt während der Test-Phase die Unit-Tests aus. Zusätzlich
generiert es jeweils einen Report.

Jar
Das “Jar”-Plugin ermöglicht das Erstellen und Signieren von Jar-Dateien.
Funktionsweise

11
JavaDoc
Das “JavaDoc”-Plugin erstellt automatisch eine Dokumentation des Sourcecodes in
Form von JavaDocs für das jeweilige Projekt. Das Ergebnis ist eine HTMLDokumentationsdate.
Funktionsweise
12
2.3 POM
Die Datei pom.xml enthält das Projekt Objekt Modell eines Projektes (Project Object Model –
POM). Die POM enthält alle relevanten Informationen über ein Projekt.
<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/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven Quick Start Archetype</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Beispiel 3 - Beispiel POM (Siehe Kapitel 3.1)
Dies ist eine sehr simple POM, enthält jedoch die Elemente die jede POM enthalten muss. Im
Folgenden eine kurze Erklärung der einzelnen Elemente:

project: Das Top-Level Element dass jede POM besitzt.

modelVersion: Beschreibt die Version des genutzten Objekt Modells der POM.

groupId: Enthält eine einzigartig identifizierbare ID der Gruppe, die an dem Projekt
arbeiten. Meist besteht die groupId auf einer Domain einer Firma.

artifactId: Dieses Element enthält eine einzigartig identifizierbare ID des jeweiligen
Projekts pro groupId.

packaging: Zeigt an wie das kompilierte Projekt gepackt werden soll. Beispiele dafür
sind JAR, WAR oder EAR.

version: Beschreibt die aktuelle Version des Projektes. Maven unterstützt die
Entwickler bei der Versionierung, das heißt dass diese meist automatisch hochgestuft
wird.
Funktionsweise
13

name: Beschreibt den Namen des Projektes.

url: Enthält die URL der Projektseite. Wird meist für die von Maven generierte
Dokumentation genutzt.

Description: Eine kurze Beschreibung des Projekts.
Die so genannten Dependencies stellen die Abhängigkeiten des Projekts dar. Eine Dependency
zeigt eine externe Bibliothek an, welches von dem Projekt benötigt wird. Maven würde diese
dann in das lokale Repository kopieren, damit es lokal nutzbar ist. Ein POM kann beliebig viele
Dependencies enthalten. Zusätzlich ist eine Vererbung von POMs möglich. Das heißt dass eine
POM ein Parent-POM besitzen kann, dessen Attribute dann alle geerbt werden. Eine
Beispielhafte Projektabhängigkeit wird in Abbildung 1 dargestellt. Zusätzlich wird verdeutlicht,
dass auch Plugins Abhängigkeiten von anderen Bibliotheken haben können.
Abbildung 1- Beispielhaftes Diagramm für Abhängigkeiten des Open-Source-Tools Shindig
5
http://shindig.apache.org – 14.12.2011
5
Funktionsweise
14
2.4 Repositories
Maven nutzt zur Abhängigkeitsverwaltung eine bestimmte Verzeichnisstruktur, welche sich
Repository nennt. Es wird zwischen dem lokalen- und dem (entfernten) Remote-Repository
unterschieden. Wird während des Build-Vorgangs eine Abhängigkeit entdeckt, versucht Maven
die benötigten Dateien im lokalen Repository zu finden. Werden sie dort gefunden, werden sie
ohne in das Projektverzeichnis kopiert zu werden, genutzt.
Können die Abhängigkeiten nicht mit Hilfe des lokalen Repositorys aufgelöst werden, wird das
sogenannte Remote-Repository genutzt. Ein Remote-Repository kann entweder öffentlich im
Internet zugänglich sein, oder privat in einem Intranet Beispielsweise von einer Firma.
Findet Maven die benötigten Dateien im Remote-Repository, werden diese in das lokale
Repository kopiert und können ab diesem Zeitpunkt lokal genutzt werden. Das heißt, dass das
lokale Repository ein Cache des Remote-Repositorys. Zusätzlich beinhaltet das lokale Repository
jedoch noch Artefakte die vom Nutzer erstellt, aber noch nicht released wurden. Ein Projekt
kann auch auf mehrere Remote-Repositories zugreifen. Diese werden dann nacheinander nach
den benötigten Daten durchsucht. Die Abhängigkeiten, also die benötigten Bibliotheken eines
Projektes werden in der Datei pom.xml definiert (siehe Kapitel 2.3).
Ein Beispiel für ein bekanntes öffentliches Remote-Repository ist das öffentliche Repository von
Apache6.
Es gibt drei Arten von Repositories, die jeweils in dem POM definiert werden:

repositories
Ein Repository für Dependencies

pluginRepositories
Ein Repository für Plugins

distributionManagement
Ein Repository für das Deployment, also ein Ziel-Repository
6
central:http://repo1.maven.org/maven/
Konfiguration
15
3. Konfiguration
Eine Anleitung, wie Maven installiert werden muss, findet sich auf der Maven Homepage7. ist
Maven installiert, kann per Kommandozeilenbefehl mvn –v getestet werden ob alles geklappt
hat. Kommandozeilenbefehle werden im folgenden mit fettem Text markiert. mvn ist der Aufruf
von Maven, alles Nachfolgende sind Parameter.
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files\apache-maven-3.0.3
Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_27\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Beispiel 4 - Beispielhafte Augabe des Befehls mvn -v
3.1 Anlegen eines Projektes
Um ein neues Projekt anzulegen, muss in der Kommandozeile folgender Befehl eingegeben
werden:
mvn archetype:generate \ DarchetypeGroupId=org.apache.maven.archetypes \ DgroupId=com.mycompany.app \ -DartifactId=my-app
Beispiel 5 - Eingabe zur Erstellung eines neuen Projektes
archetype:generate steht für ein Maven-Goal (siehe Kapitel 2.1). Ein Maven-Goal ist in etwa
gleichbedeutend mit einem Ant-Target (siehe Kapitel 4.1). Die restlichen Werte sind Argumente
die für das Goal relevant sind. Archetypes sind Templates von Projekten8, die
Beispielimplementierungen für bestimmte Programmtypen liefern. Mitgeliefert mit Maven
werden viele verschiedene Archetypen, von einer simplen Anwendung bis hin zum komplexen
Web-Tool.
Nachdem der Befehl ausgeführt wurde fällt auf, dass ein Verzeichnis namens „my-app“ erstellt
wurde, welches das neue Projekt enthält. Zusätzlich enthält das Verzeichnis eine automatisch
7
8
http://maven.apache.org/download.html - 13.12.2011
http://maven.apache.org/guides/introduction/introduction-to-archetypes.html - 13.12.2011
Konfiguration
16
erstellte pom.xml. Die in diesem Beispiel erstellte POM ist in Kapitel 2.3 zu finden. Die erzeugten
Verzeichnisse halten sich an das Maven Standard Layout. Wie schon beschrieben wird der
Sourcecode des Projekts in einem anderen Verzeichnis gesichert als die Unit-Test-Dateien.
3.2 Erstellen des Projektes
Um nun das erstellte Projekt zu erstellen und zu paketieren, muss im Verzeichnis des Projekts
der Befehl mvn install aufgerufen werden. Wurde dieser Befehl aufgerufen, findet sich im
Unterverzeichnis „Target“ des Projektverzeichnisses die Datei „my-app-1.0-Snapshot.jar“. Diese
Datei kann dann als Javaprogramm ausgeführt werden.
Mit dem Befehl mvn install wird das erstellte Projekt kompiliert, getestet, paketiert und
anschließend im lokalen Repository installiert.
3.3 Hinzufügen einer Abhängigkeit
Will der Nutzer nun eine Bibliothek nutzen, die in einem Remote-Repository verfügbar ist, muss
er sein POM ergänzen. Dann wird das jeweilige Artefakt9 automatisch in das lokale Repository
geladen und kann genutzt werden. Im Folgenden ein Beispiel:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
</dependency>
Beispiel 6 - Beispiel Dependency
In diesem Beispiel wird die Logging-Bibliothek log4j in der Version 1.2.12 heruntergeladen, wird
in das Verzeichnis log4j/log4j/1.2.14/ des lokalen Repositories kopiert und kann somit genutzt
werden.
3.4 Weitere Möglichkeiten
Weitere mögliche Befehle sind den Phasen des Default-Lifecycles ähnlich. Es gibt für die meisten
Phasen Befehle, die diese Ausführen. Im folgenden sind die wichtigsten beschrieben.

9
Kompilieren
Vom Nutzer erstelltes, kompiliertes und packetiertes Programm
Konfiguration
17
o mvn compile – Der Ordner target/classes/ wird im Projektverzeichnis angelegt
und die Klassen aus dem Ordner src/main/java/ werden dort hinein kompiliert.

Unit-Tests ausführen
o mvn test – Der Ordner target/test-classes wird im Projektverzeichnis angelegt.
Daraufhin werden alle Testklassen kompiliert und in besagten Ordern verschoben.
Anschließend werden die Unit-Tests ausgeführt.

Packen/Installieren
o mvn package – Erzeugt die Ausführbare JAR-Datei des Projekts
o mvn install – siehe Kapitel 3.2

Aufräumen
o mvn clean – Alle für den Build-Vorgang benötigten Dateien werden gelöscht.
Praktisch bedeutet das, dass der Target Ordner im Projektverzeichnis gelöscht wird.
Die Verschiedenen Aufrufe lassen sich teilweise auch kombinieren. Das bekannteste Beispiel ist
dabei mvn clean package. Bei diesem Aufruf wird erst der clean-Befehl ausgeführt, und
dann der package-Befehl. Das bedeutet, dass der Target-Ordner gelöscht wird, und
anschließend das Projekt neu kompiliert, getestet und packetiert wird.
Vergleich mit Apache Ant
18
4. Vergleich mit Apache Ant
Das folgende Kapitel soll eine kurze Einführung in Apache Ant geben. Daraufhin soll Apache Ant
mit Apache Maven verglichen werden. Allerdings wird nur die Buildmanagement-Funktion von
Maven für den Vergleich genutzt, da Ant keine Möglichkeit für Plugins bietet und somit auch
keine Management-Funktionen wie Maven.
4.1 Ant Grundlagen
Im Gegensatz zu Maven, welches über weitere Fähigkeiten verfügt, ist Ant ein Werkzeug
welches exklusiv für das automatisierte Builden von Quelltexten zuständig ist. Ant ist ein
Apronym für „Another Neat Tool“ und wird seit 1999 entwickelt. Außerdem ist Ant Open Source
und in Java geschrieben.
Gesteuert wird Ant von der sogenannten build.xml-Datei, auch genannt Build-Datei. In dieser
Projekt-Datei wird ein Projekt definiert, welches Targets (Ziele) enthält. Targets sollen so viele
Tätigkeiten, Beispielsweise das Builden, wie möglich abdecken, die bei einem Software-Projekt
anfallen. Zwischen diesen Targets können Abhängigkeiten zu anderen Targets definiert werden,
welche beim Aufruf von Ant aufgelöst und abgearbeitet werden. Hat ein Target eine
Abhängigkeit zu einem oder mehreren anderen Targets, muss nur dieses aufgerufen werden um
alle notwendigen Schritte abzuarbeiten.
<target name="build" depends="clean" description="Baut die komplette Anwendung">
Beispiel 7 - Beispiel Target
An diesem Beispiel erkennt man gut die Abhängigkeiten. Damit das Ziel „build“ ausgeführt wird,
muss erst „clean“ ausgeführt werden.
Ein Target besteht wiederum aus Tasks (Aufgaben). Tasks sind vergleichbar mit Funktionen in
Programmiersprachen. Insgesamt verfügt Ant über mehr als 150 Tasks, Beispiele dafür sind
copy, delete oder move.
<!-- Verzeichis anlegen -->
<mkdir dir="${build.classes}"/>
Beispiel 8 - Beispiel Task
Vergleich mit Apache Ant
19
"${build.classes}" stellt hier eine Variable dar, die vorher per
<property name="build.classes" value="bin" />
Beispiel 9 - Beispiel Property
definiert wird. In diesem Fall soll das Verzeichnis “bin” angelegt werden. Daran sieht man dass
genaue Vorgaben braucht. Es muss zum Beispiel genau vorgegeben bekommen in welchem
Verzeichnis welche Information liegt, da es diesbezüglich keinerlei Standardinformationen
vorgegeben hat.
4.2 Vergleich mit Maven
Ant kennt im Gegensatz zu Maven keine Konventionen für eine Verzeichnisstruktur oder für
Vorgänge. Im Build-Skript von Ant muss manuell definiert werden, wo sich der Sourcecode
befindet, wo sich das Ausgabeverzeichnis befinden soll und in welcher Reihenfolge die Befehle
ausgeführt werden sollen. Ant geht also prozedural vor. Maven geht deklarativ vor. Im Falle von
Maven bedeutet dies, dass alle Strukturen bereits bestehen, und der Entwickler nur den Inhalt
füllt. Der Entwickler muss nur die pom.xml erzeugen und die Daten (Projektsourcen, Unit-Tests)
im jeweiligen Standard-Verzeichnis abgelegen. Der Rest, also der Build-Vorgang, das
Kompilieren usw. geschieht dann ohne zutun des Nutzers.
Zudem kennt Ant keine Lebenszyklen. Mit Ant müssen Targets und deren Abhängigkeiten
definiert und die Abfolge aller Schritte im Build-Script muss manuell festgelegt werden. Maven
führt wiederum eine Reihe von fest definierten Abläufen durch (siehe Lifecycles, Kapitel 2.1).
Theoretisch müsste sich ein Maven-Nutzer nur einen einzigen Befehl merken, da alle vorherigen
Schritte automatisch abgearbeitet werden. Ein Ant-Nutzer müsste für den gleichen Effekt ein
ganzes Skript schreiben. Im Grunde muss ein Ant-Nutzer für jede anfallende Aufgabe ein
eigenes Skript erstellen. Möchte ein Nutzer mit Maven nur sein Projekt testen, muss er nur den
Test-Befehl aufrufen. Alle nötigen Schritte werden hierbei automatisch erledigt.
Ant hat jedoch gegenüber Maven den Vorteil der Freiheit, die der Entwickler des Build-Skriptes
hat. Der Entwickler kann frei entscheiden was das Skript machen soll und in welcher Reihenfolge
dies geschehen soll. Maven hat hier das „Problem“ der festen Struktur, wodurch einige
Freiheiten verloren gehen.
Vergleich mit Apache Ant
20
Maven profitiert hier von der einfacheren Nutzbarkeit. Der Nutzer muss im Grunde nichts
manuell konfigurieren und kann sich der Entwicklung widmen. Ant hat den großen Nachteil dass
keine Repositories genutzt werden können. Dadurch muss der Nutzer bei Bedarf alle
Bibliotheken manuell updaten.
Trotzdem schließen sich Maven und Ant nicht gegenseitig aus. Wurden zum Beispiel bereits sehr
komplexe Skripte für Ant geschrieben, oder sollen Probleme gelöst werden, in einer Art die sich
nicht an die Normen von Maven hält, können diese Skripte auch in Maven genutzt werden. Ant
wird in Form eines Maven-Plugins eingebunden. Es können also Maven-Plugins in Ant
geschrieben sein oder bestimmte Phasen des Lifecycles Ant-Skripte ausführen.
Nicht zu verwechseln mit der erleichterten Integration von neuen Entwicklern in ein Projekt ist
die generelle Erlernbarkeit der Tools. Muss sich ein Entwickler in Maven einarbeiten, muss
dieser sich alle Strukturen, Funktionen und Möglichkeiten einprägen. Dies kann durchaus Zeit in
anspruch
nehmen.
Im
Gegensatz
dazu
nutzt
Ant
in
seinen
Build-Skripten
eine
Programmiersprachen ähnliche Syntax. Dadurch wird es einem Entwickler erleichtert sich in Ant
einzuarbeiten, da dieses schon bekannten Strukturen ähnelt.
Fazit
21
5. Fazit
Dieses Kapitel soll diese Seminararbeit kurz zusammenfassen und einen Ausblick bieten, was mit
Maven noch möglich ist, da diese Seminararbeit sich auf den Buildmanagement-Aspekt Mavens
konzentriert hat.
5.1 Zusammenfassung
In der vorliegenden Arbeit wurde dem Leser eine Einführung in die Builmanagement-Aspekte
des Tools Apache Maven gegeben.
Die Kapitel 1 und 2 sollen dem Leser den theoretischen Hintergrund von Maven erklären.
Kapitel 3 wendet sich der technischen Seite, bzw. der Realisierung eines Projektes zu. In Kapitel
3 wurde ein Vergleich mit dem wohl verbreitetsten Konkurenztool Apache Ant vorgenommen.
5.2 Ausblick
Maven ist nach 9 Jahren10 immer noch in aktiver Entwicklung, das heißt, dass das noch
kontinuierlich neue Funktionen hinzukommen. Momentan ist Maven in der Version 3.0.311
verfügbar. Bei den Arbeiten an Version 3 ist es den Entwicklern besonders wichtig, eine
größtmögliche Kompatibilität zu Maven 1 bzw. Maven 2 zu ermöglichen. Die meisten Projekte
werden bei einem Update auf Maven 3 keine Umstellungen benötigen. In der neuen Version
wurden zudem etliche Funktionen im Kern von Maven neugeschrieben, zusätzlich wurden
kompatible Sprachen wie Ruby hinzugefügt. In einem neuen experimentellen Feature werden
Multi-Core-Prozessoren unterstützt. Damit wird die Last des Build-Vorgangs auf mehrere Kerne
aufgeteilt.
Mit Hilfe von Server-Tools wie Jenkins12 ist es möglich, in bestimmten Abständen automatisch
den Build-Vorgang zu starten. Dieses Vorgehen fällt in den Bereich der Kontinuierlichen
Integration. Am bekanntesten ist hierbei der so genannte Nightly-Build, bei dem jede Nacht ein
neuer Build erstellt wird. Bei diesem Vorgang soll automatisch getestet, kompiliert und
eventuell sogar auf das Zielsystem deployed werden. Dies hat mehrere Vorteile. Zum einen gibt
es dadurch regelmäßige Tests, da bei jedem Build-Vorgang kompiliert und die Unit-Tests
10
In aktiver Entwicklung seit 2002
Stand Dezember 2011
12
Webbasiertes System für kontinuierliche Integration für beispielsweise Maven Projekte.
11
Fazit
22
durchlaufen werden. Zum anderen gibt es jeden Tag (oder ein anderer eingestellter Zeitraum)
eine aktuelle Version die ausführbar, und damit produktiv testbar ist.
Die oft gelobten Konventionen von Maven, die dem Nutzer zwar Arbeit abnehmen, nehmen
dem Nutzer jedoch auch einen erheblichen Teil an Freiheit. Genau diese Freiheit ist ein Vorteil
von Apache Ant. Ant-Skripte können zwar auch mit Maven ausgeführt werden, was ein
vollständiges Build-Skript jedoch nicht ersetzt. Mit Apache Ivy gibt es mittlerweile ein
Konkurenztool für Maven, auf der Basis von Apache Ant13. Apache Ivy erweitert Apache Ant um
Buildmanagement-Aspekte. Mit Ivy bekommt Ant so die Möglichkeit Repositories zu nutzen,
womit Maven einen seiner größten Vorteile verliert. Da jedoch Ivy noch nicht so lange in
Entwicklung ist wie Maven gibt es für dieses Tool deutlich weniger Repositories.
In absehbarer Zeit wird Maven das verbreitetste Buildmanagement-Tool mit vergleichbarem
Funktionsumfang bleiben. Die Konkurrenzprodukte wie Ivy, Gradle oder Buildr sind noch nicht
ausgereift oder verbreitet genug um Maven zu ersetzen. Mittlerweile wird Maven von vielen
Firmen und Open-Source-Projekten genutzt wodurch die Anzahl der verfügbaren Plugins und
Repositories stetig wächst. Ein Vergleich aus dem Jahre 200514 zeigt, dass es zu diesem
Zeitpunkt bereits mehr als 8000 verfügbare Bibliotheken im Maven Repository gab. Zur selben
Zeit gab es im Ivyrep nur etwa 30 Bibliotheken.
13
14
Seit 2004
http://docs.codehaus.org/display/MAVEN/Feature+Comparisons – Stand 13.12.2011
Literaturverzeichnis
23
6. Literaturverzeichnis

Apache Ant Project. (kein Datum). Abgerufen am 14.12.2011 von http://ant.apache.org/

Apache
Maven
Project.
(kein
Datum).
Abgerufen
am
13.12.2011
von
http://maven.apache.org/

Ivy - The agile dependency manager. (kein Datum). Abgerufen am 14.12.2011 von
http://ant.apache.org/ivy/

Jenkins. Abgerufen am 14.12.2011 von http://jenkins-ci.org/

Spiller, M. (2009). Maven 2 Konfigurationsmanagement mit Java. mitp.

Thomas Locher, T. O. (kein Datum). Maven Guide. Abgerufen am 13.12.2011 von
http://www.scribd.com/doc/17571160/Maven-Guide-German
Eidesstattliche Erklärung
24
7. Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema „Grundlagen des
Buildmanagement-Tools Apache Maven“ selbstständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften
wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher
oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war.
Name: Sinan Böcker
Aachen, den 14.12.2011
Unterschrift der Studentin / des Studenten