Grundlagen des BuildmanagementTools Apache Maven

Seminararbeit im Studiengang Scientific Programming vorgelegt von Sinan Bcker Matr.-Nr.: 836951 am 15. Dezember 2011 an der Fachhochschule Aachen

Erstprfer: Zweitprfer:

Prof. Dr. rer. nat. Bodo Kraft Dipl.-Inf. Arne Rache

Abstract

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 mglichst viele Aufgaben abnehmen und diese automatisieren, wie beispielsweise das Erstellen, das Testen oder die Distribution der Software. Besonders bei groen 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 populren Buildmanagement-Tool Apache Ant verglichen.

Inhaltsverzeichnis

Inhaltsverzeichnis
Abstract ............................................................................................................................................ 1 Inhaltsverzeichnis ............................................................................................................................. 2 1. Einleitung .................................................................................................................................. 3 1.1 1.2 1.3 2. Was ist Maven? ................................................................................................................. 3 Motivation fr Buildmanagement ..................................................................................... 3 Maven Grundlagen ............................................................................................................ 4

Funktionsweise ......................................................................................................................... 7 2.1 2.2 2.3 2.4 Lifecycles ............................................................................................................................ 7 Plugins ................................................................................................................................ 9 POM ................................................................................................................................. 12 Repositories ..................................................................................................................... 14

3.

Konfiguration .......................................................................................................................... 15 3.1 3.2 3.3 3.4 Anlegen eines Projektes .................................................................................................. 15 Erstellen des Projektes .................................................................................................... 16 Hinzufgen einer Abhngigkeit ....................................................................................... 16 Weitere Mglichkeiten .................................................................................................... 16

4.

Vergleich mit Apache Ant ....................................................................................................... 18 4.1 4.2 Ant Grundlagen................................................................................................................ 18 Vergleich mit Maven........................................................................................................ 19

5.

Fazit ......................................................................................................................................... 21 5.1 5.2 Zusammenfassung ........................................................................................................... 21 Ausblick ............................................................................................................................ 21

6. 7.

Literaturverzeichnis ................................................................................................................ 23 Eidesstattliche Erklrung......................................................................................................... 24

Einleitung

1. Einleitung
Die vorliegende Seminararbeit behandelt das Buildmanagement-Tool Maven. Sie soll dem Leser eine Einfhrung in Maven bieten und diesen motivieren, es in Projekten zu nutzen. Das Thema Grundlagen des Buildmanagement-Tools Maven wurde gewhlt, 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 BuildFunktionalitten bietet Maven viele Projektrelevante Funktionen, wie das Erstellen von Berichten bzw. Reports oder das Generieren von Webseiten.

1.2 Motivation fr Buildmanagement

Eine der Herausforderungen bei groen Software-Projekten ist es, dem Entwickler so viel Zeit wie mglich 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 grtenteils durch verschiedenste Automatisierungen. Zustzlich ist es mit Maven mglich 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 bentigten Resourcen, d.h. bentigte Pakete und Bibliotheken mssen 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

beispielsweise mit Hilfe der Plugins automatisiert JavaDocs1 oder Fehler-Reports erstellen, es muss also kein externes Tool dafr genutzt werden. Frher gab es viele Diskussionen um das richtige Vorgehen und genauso viele Anstze fr BuildKonzepte. Im Grunde waren diese Anstze aber ineffizient, da keine Konventionen genutzt wurden. Im Laufe der Zeit wurden jedoch beispielsweise mit Maven Konventionen geschaffen. Die Bedeutung der Konventionen wird im nchsten Kapitel (1.3) verdeutlicht. Der Entwickler soll bei mglichst vielen Aufgaben untersttzt werden, welche im Idealfall sogar automatisiert werden. Maven ldt alle bentigten Pakete bei Bedarf aus einem zentralen Repository auf das lokale Repository des Entwicklers herunter, wodurch jeder Entwickler automatisch Zugriff auf alle bentigten und aktuellsten Konfigurationen und Bibliotheken hat. Eine genauere Erklrung von Repositories findet sich in Kapitel 2.4.

1.3 Maven Grundlagen

Der Grundsatz von Maven ist Konvention vor Konfiguration . Das heit, dass ein groer 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 primr am eigentlichen Projektcode bzw. dem Inhalt des Projektes arbeiten, und mglichst wenig an Konfigurationen, Strukturen, oder Ablufen, die zur Kompilierung oder Verffentlichung ntig sind. Die Konventionen uern 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, lsst Maven den Entwickler die meisten Vorgaben an die eigenen Bedrfnisse anpassen. Es ist beispielsweise mglich 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 fr erfahrene Maven-Entwickler sehr bersichtlich. Zustzlich knnen dadurch Funktionen auf verschiedene Projekte angewendet werden, ohne Anpassungen vornehmen zu mssen. Dies bildet auch die Basis fr das PluginSystem Mavens bildet.

Automatische Softwaredokumentation des Java-Sourcecodes

Einleitung

simple/ simple/pom.xml /src/ /src/main/ /main/java /src/test/ /test/java

Beispiel 1 - Die automatisch erstellte Verzeichnisstruktur

Um Abhngigkeiten 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 fr 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 bentigt werden. Werden weitere Bibliotheken oder neue Versionen von Bibliotheken bentigt, werden diese automatisch in das Repository kopiert bzw. aktualisiert. Dadurch entfllt die Notwendigkeit einer manuellen Verwaltung der Bibliotheken.

Erstellung eines Programmes aus dem Sourcecode

Einleitung

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 enthlt, die zur Erstellung eines Builds ntig ist. Da die Reihenfolge der Phasen von Maven feststeht, ist auerdem keine Analyse bzw. Erstellung von Build-Skripten ntig. 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 vollstndige Super-POM kann auf der Maven-Homepage gefunden werden3.

http://maven.apache.org/ - 14.12.2011

Funktionsweise

2. Funktionsweise
Maven hat ein fest definiertes Modell eines Projekts. Diese Modell ermglicht: Abhngigkeits-Verwaltung Die Indentifizierbarkeit eines Projektes mittels Gruppenkennung, Artefaktkennung4 und Version ermglicht eine Abhngigkeitsverwaltung. Repositories Die in den POMs angegebenen Abhngigkeiten machen es mglich, Sammlungen von Bibliotheken zu erstellen und diese den Nutzern zur Verfgung zu stellen. Dabei gibt es Remote-Repositories, welche Bibliotheken fr den bzw. die Nutzer zur Verfgung 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 spterer Erluterung) Wiederverwendung Ein einzelnes Plugin kann fr verschiedene Zwecke genutzt werden. Siehe Kapitel 2.2. Integration Durch das genau definierte Modell knnen 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 enthlt alle Phasen die ntig fr den Build-Vorgang sind. Ebenfalls definiert im Lifecycle ist die Distribution. Fr den Entwickler bedeutet das, dass er sich keine breite Auswahl von Befehlen merken muss, sondern nur einige wenige. Die POM des Projektes sorgt fr das Ergebnis. Standartmig enthlt Maven drei Lifecycles: default, clean und site. Clean beseitigt alles was fr das Projekt nicht direkt bentigt wird, beispielsweise die Kompilierten-Dateien des

Artefakt: Objekt in der Softwareentwicklung

Funktionsweise

vorherigen Build-Vorgangs. Site ist zustndig fr die Projektdokumentation. Auf den DefaultLifecycle wird im Folgenden genauer eingegangen. Der Default-Lifecycle enthlt folgende Phasen: Validate berprft das Projekt auf Fehler und stellt sicher dass alle bentigten 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). Fr diese Tests muss das Projekt in der Regel nicht gepackt und deployed sein. Package Packt den kompilierten Sourcecode in das gewnschte Format. Ein Beispiel dafr wre das Jar-Format. Integration-test Deployment in eine Testumgebung. Verify Testet ob das Paket valide ist und ob es den Qualitts-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 fr andere Entwickler und Projekte zur Verfgung steht. Build-Phasen eines Lifecycles werden sequentiell ausgefhrt, die Reihenfolge untereinander ist nicht vernderbar. Wird eine Phase aufgerufen, werden automatisch alle vorher ntigen Phasen durchlaufen. Jede der Phasen besteht wiederum aus so genannten Goals (Deutsch: Ziel). Ein

Funktionsweise

Goal hat eine hnliche Aufgabe wie eine Phase, beide definieren eine bestimmte Aufgabe. Ein Goal fhrt jedoch eine bestimmte Funktionalitt eines Plugins aus. Um also das Projekt in das Remote-Repository zu kopieren muss nur der Deploy-Befehl aufgerufen werden, womit automatisch alle anderen bentigten Schritte durchgefhrt wrden. Will der Nutzer beispielsweise seine Unit-Tests ausfhren, msste er den Test-Befehl aufrufen. Damit wrden als erstes der Sourcecode validiert werden, dann der Sourcecode kompiliert werden und als letztes die Unit-Tests aufgerufen werden.

2.2 Plugins
Das Grundgerst 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 heit dass die Hauptverantwortung auf Plugins fllt. Zum Beispiel besitzt Maven keine Mglichkeit zum Ausfhren von JUnit-Tests. Diese werden von einem Plugin durchgefhrt, welches fr die TestPhase zustndig 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 groe Bibliotheken. Der Nutzer muss nichts tun um Updates der Plugins zu erhalten, da dies von Maven geregelt wird. Das heit gleichzeitig auch dass der Nutzer in seinem Projekt so gut wie keine Anpassungen am Projektcode machen muss um neuen Code zu untersttzen, vorrausgesetzt die Abwrtskompatibilitt des Plugins ist erhalten geblieben. Die einzige Bentigte 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 fr ein Plugin ist das Surefire-Plugin, welches fr die Aufhrung von UnitTests zustndig ist. Es ermglicht unter anderem JUnit3- und JUnit4-Tests, sowie TestNG-Tests.

Funktionsweise

10

Hierbei wurde sehr auf Abwrtskompatibilitt geachtet, damit beispielsweise Nutzer von JUnit3Tests diese auch weiterhin ohne Anpassungen nach einem Update weiternutzen knnen. Durch dieses Plugin-Konzept ist es leicht mglich Maven um weitere Funktionalitten zu erweitern. Nachfolgend einige populre Maven-Plugins: Clean Das Clean-Plugin hat die Aufgabe, die Dateien und Verzeichnisse, die Maven whrend dem Builden generiert, zu lschen. Das Clean-Plugin ist an die Clean-Phase gebunden, kann jedoch auch manuell aufgerufen werden. Compiler Das Compiler-Plugin ist zustndig fr die Kompilierung des Quellcodes. Der Standardcompiler ist dabei javac, es knnen allerdings auch beispielsweise die Compiler von .NET oder C# genutzt werden. Deploy Das Deploy Plugin wird hauptschlich whrend der Deploy-Phase (siehe Kapitel 2.1) genutzt. Es ist dafr zustndig, die Artefakte des Entwicklers einem Remote-Repository (siehe Kapitel 2.4) hinzuzufgen, um es anderen Entwicklern zur Verfgung zu stellen. Eclipse Das Eclipse-Plugin ermglicht es, aus dem Maven-Projekt ein Eclipse-Projekt zu generieren. Install Das Install-Plugin fgt 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 fhrt whrend der Test-Phase die Unit-Tests aus. Zustzlich generiert es jeweils einen Report. Jar Das Jar-Plugin ermglicht das Erstellen und Signieren von Jar-Dateien.

Funktionsweise JavaDoc

11

Das JavaDoc-Plugin erstellt automatisch eine Dokumentation des Sourcecodes in Form von JavaDocs fr das jeweilige Projekt. Das Ergebnis ist eine HTMLDokumentationsdate.

Funktionsweise

12

2.3 POM
Die Datei pom.xml enthlt das Projekt Objekt Modell eines Projektes (Project Object Model POM). Die POM enthlt 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, enthlt jedoch die Elemente die jede POM enthalten muss. Im Folgenden eine kurze Erklrung der einzelnen Elemente:

project: Das Top-Level Element dass jede POM besitzt. modelVersion: Beschreibt die Version des genutzten Objekt Modells der POM. groupId: Enthlt eine einzigartig identifizierbare ID der Gruppe, die an dem Projekt arbeiten. Meist besteht die groupId auf einer Domain einer Firma.

artifactId: Dieses Element enthlt eine einzigartig identifizierbare ID des jeweiligen Projekts pro groupId.

packaging: Zeigt an wie das kompilierte Projekt gepackt werden soll. Beispiele dafr sind JAR, WAR oder EAR.

version: Beschreibt die aktuelle Version des Projektes. Maven untersttzt die Entwickler bei der Versionierung, das heit dass diese meist automatisch hochgestuft wird.

Funktionsweise

13

name: Beschreibt den Namen des Projektes. url: Enthlt die URL der Projektseite. Wird meist fr die von Maven generierte Dokumentation genutzt.

Description: Eine kurze Beschreibung des Projekts.

Die so genannten Dependencies stellen die Abhngigkeiten des Projekts dar. Eine Dependency zeigt eine externe Bibliothek an, welches von dem Projekt bentigt wird. Maven wrde diese dann in das lokale Repository kopieren, damit es lokal nutzbar ist. Ein POM kann beliebig viele Dependencies enthalten. Zustzlich ist eine Vererbung von POMs mglich. Das heit dass eine POM ein Parent-POM besitzen kann, dessen Attribute dann alle geerbt werden. Eine Beispielhafte Projektabhngigkeit wird in Abbildung 1 dargestellt. Zustzlich wird verdeutlicht, dass auch Plugins Abhngigkeiten von anderen Bibliotheken haben knnen.

Abbildung 1- Beispielhaftes Diagramm fr Abhngigkeiten des Open-Source-Tools Shindig

http://shindig.apache.org 14.12.2011

Funktionsweise

14

2.4 Repositories
Maven nutzt zur Abhngigkeitsverwaltung eine bestimmte Verzeichnisstruktur, welche sich Repository nennt. Es wird zwischen dem lokalen- und dem (entfernten) Remote-Repository unterschieden. Wird whrend des Build-Vorgangs eine Abhngigkeit entdeckt, versucht Maven die bentigten Dateien im lokalen Repository zu finden. Werden sie dort gefunden, werden sie ohne in das Projektverzeichnis kopiert zu werden, genutzt. Knnen die Abhngigkeiten nicht mit Hilfe des lokalen Repositorys aufgelst werden, wird das sogenannte Remote-Repository genutzt. Ein Remote-Repository kann entweder ffentlich im Internet zugnglich sein, oder privat in einem Intranet Beispielsweise von einer Firma. Findet Maven die bentigten Dateien im Remote-Repository, werden diese in das lokale Repository kopiert und knnen ab diesem Zeitpunkt lokal genutzt werden. Das heit, dass das lokale Repository ein Cache des Remote-Repositorys. Zustzlich 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 bentigten Daten durchsucht. Die Abhngigkeiten, also die bentigten Bibliotheken eines Projektes werden in der Datei pom.xml definiert (siehe Kapitel 2.3). Ein Beispiel fr 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 fr Dependencies pluginRepositories Ein Repository fr Plugins distributionManagement Ein Repository fr das Deployment, also ein Ziel-Repository

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 fr 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 fr das Goal relevant sind. Archetypes sind Templates von Projekten8, die Beispielimplementierungen fr bestimmte Programmtypen liefern. Mitgeliefert mit Maven werden viele verschiedene Archetypen, von einer simplen Anwendung bis hin zum komplexen Web-Tool. Nachdem der Befehl ausgefhrt wurde fllt auf, dass ein Verzeichnis namens my-app erstellt wurde, welches das neue Projekt enthlt. Zustzlich enthlt 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 ausgefhrt werden. Mit dem Befehl mvn install wird das erstellte Projekt kompiliert, getestet, paketiert und anschlieend im lokalen Repository installiert.

3.3 Hinzufgen einer Abhngigkeit

Will der Nutzer nun eine Bibliothek nutzen, die in einem Remote-Repository verfgbar ist, muss er sein POM ergnzen. 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 Mglichkeiten

Weitere mgliche Befehle sind den Phasen des Default-Lifecycles hnlich. Es gibt fr die meisten Phasen Befehle, die diese Ausfhren. Im folgenden sind die wichtigsten beschrieben. 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 ausfhren o mvn test Der Ordner target/test-classes wird im Projektverzeichnis angelegt. Daraufhin werden alle Testklassen kompiliert und in besagten Ordern verschoben. Anschlieend werden die Unit-Tests ausgefhrt. Packen/Installieren o mvn package Erzeugt die Ausfhrbare JAR-Datei des Projekts o mvn install siehe Kapitel 3.2 Aufrumen o mvn clean Alle fr den Build-Vorgang bentigten Dateien werden gelscht. Praktisch bedeutet das, dass der Target Ordner im Projektverzeichnis gelscht 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 ausgefhrt, und dann der package-Befehl. Das bedeutet, dass der Target-Ordner gelscht wird, und anschlieend das Projekt neu kompiliert, getestet und packetiert wird.

Vergleich mit Apache Ant

18

4. Vergleich mit Apache Ant

Das folgende Kapitel soll eine kurze Einfhrung in Apache Ant geben. Daraufhin soll Apache Ant mit Apache Maven verglichen werden. Allerdings wird nur die Buildmanagement-Funktion von Maven fr den Vergleich genutzt, da Ant keine Mglichkeit fr Plugins bietet und somit auch keine Management-Funktionen wie Maven.

4.1 Ant Grundlagen

Im Gegensatz zu Maven, welches ber weitere Fhigkeiten verfgt, ist Ant ein Werkzeug welches exklusiv fr das automatisierte Builden von Quelltexten zustndig ist. Ant ist ein Apronym fr 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) enthlt. Targets sollen so viele Ttigkeiten, Beispielsweise das Builden, wie mglich abdecken, die bei einem Software-Projekt anfallen. Zwischen diesen Targets knnen Abhngigkeiten zu anderen Targets definiert werden, welche beim Aufruf von Ant aufgelst und abgearbeitet werden. Hat ein Target eine Abhngigkeit 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 Abhngigkeiten. Damit das Ziel build ausgefhrt wird, muss erst clean ausgefhrt werden. Ein Target besteht wiederum aus Tasks (Aufgaben). Tasks sind vergleichbar mit Funktionen in Programmiersprachen. Insgesamt verfgt Ant ber mehr als 150 Tasks, Beispiele dafr sind copy, delete oder move.
<!-- Verzeichis anlegen --> <mkdir dir="${build.classes}"/>
Beispiel 8 - Beispiel Task

Vergleich mit Apache Ant "${build.classes}" stellt hier eine Variable dar, die vorher per <property name="build.classes" value="bin" />
Beispiel 9 - Beispiel Property

19

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 diesbezglich keinerlei Standardinformationen vorgegeben hat.

4.2 Vergleich mit Maven

Ant kennt im Gegensatz zu Maven keine Konventionen fr eine Verzeichnisstruktur oder fr Vorgnge. 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 ausgefhrt 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 fllt. 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 mssen Targets und deren Abhngigkeiten definiert und die Abfolge aller Schritte im Build-Script muss manuell festgelegt werden. Maven fhrt wiederum eine Reihe von fest definierten Ablufen durch (siehe Lifecycles, Kapitel 2.1). Theoretisch msste sich ein Maven-Nutzer nur einen einzigen Befehl merken, da alle vorherigen Schritte automatisch abgearbeitet werden. Ein Ant-Nutzer msste fr den gleichen Effekt ein ganzes Skript schreiben. Im Grunde muss ein Ant-Nutzer fr jede anfallende Aufgabe ein eigenes Skript erstellen. Mchte ein Nutzer mit Maven nur sein Projekt testen, muss er nur den Test-Befehl aufrufen. Alle ntigen Schritte werden hierbei automatisch erledigt. Ant hat jedoch gegenber 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 groen Nachteil dass keine Repositories genutzt werden knnen. Dadurch muss der Nutzer bei Bedarf alle Bibliotheken manuell updaten. Trotzdem schlieen sich Maven und Ant nicht gegenseitig aus. Wurden zum Beispiel bereits sehr komplexe Skripte fr Ant geschrieben, oder sollen Probleme gelst werden, in einer Art die sich nicht an die Normen von Maven hlt, knnen diese Skripte auch in Maven genutzt werden. Ant wird in Form eines Maven-Plugins eingebunden. Es knnen also Maven-Plugins in Ant geschrieben sein oder bestimmte Phasen des Lifecycles Ant-Skripte ausfhren. 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 Mglichkeiten einprgen. 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 mglich ist, da diese Seminararbeit sich auf den Buildmanagement-Aspekt Mavens konzentriert hat.

5.1 Zusammenfassung
In der vorliegenden Arbeit wurde dem Leser eine Einfhrung in die Builmanagement-Aspekte des Tools Apache Maven gegeben. Die Kapitel 1 und 2 sollen dem Leser den theoretischen Hintergrund von Maven erklren. 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 heit, dass das noch kontinuierlich neue Funktionen hinzukommen. Momentan ist Maven in der Version 3.0.311 verfgbar. Bei den Arbeiten an Version 3 ist es den Entwicklern besonders wichtig, eine grtmgliche Kompatibilitt zu Maven 1 bzw. Maven 2 zu ermglichen. Die meisten Projekte werden bei einem Update auf Maven 3 keine Umstellungen bentigen. In der neuen Version wurden zudem etliche Funktionen im Kern von Maven neugeschrieben, zustzlich wurden kompatible Sprachen wie Ruby hinzugefgt. In einem neuen experimentellen Feature werden Multi-Core-Prozessoren untersttzt. Damit wird die Last des Build-Vorgangs auf mehrere Kerne aufgeteilt. Mit Hilfe von Server-Tools wie Jenkins12 ist es mglich, in bestimmten Abstnden automatisch den Build-Vorgang zu starten. Dieses Vorgehen fllt 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 regelmige Tests, da bei jedem Build-Vorgang kompiliert und die Unit-Tests
10 11

In aktiver Entwicklung seit 2002 Stand Dezember 2011 12 Webbasiertes System fr kontinuierliche Integration fr beispielsweise Maven Projekte.

Fazit

22

durchlaufen werden. Zum anderen gibt es jeden Tag (oder ein anderer eingestellter Zeitraum) eine aktuelle Version die ausfhrbar, 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 knnen zwar auch mit Maven ausgefhrt werden, was ein vollstndiges Build-Skript jedoch nicht ersetzt. Mit Apache Ivy gibt es mittlerweile ein Konkurenztool fr Maven, auf der Basis von Apache Ant13. Apache Ivy erweitert Apache Ant um Buildmanagement-Aspekte. Mit Ivy bekommt Ant so die Mglichkeit Repositories zu nutzen, womit Maven einen seiner grten Vorteile verliert. Da jedoch Ivy noch nicht so lange in Entwicklung ist wie Maven gibt es fr 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 verfgbaren Plugins und Repositories stetig wchst. Ein Vergleich aus dem Jahre 200514 zeigt, dass es zu diesem Zeitpunkt bereits mehr als 8000 verfgbare 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 Erklrung

24

7. Eidesstattliche Erklrung
Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema Grundlagen des Buildmanagement-Tools Apache Maven selbststndig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausfhrungen, die anderen Schriften wrtlich oder sinngem entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder hnlicher Fassung noch nicht Bestandteil einer Studien- oder Prfungsleistung war.

Name: Sinan Bcker Aachen, den 14.12.2011 Unterschrift der Studentin / des Studenten