Grundlagen des Buildmanagement- Tools Apache Maven

Transkript

1 Grundlagen des Buildmanagement- Tools Apache Maven Seminararbeit im Studiengang Scientific Programming vorgelegt von Sinan Böcker Matr.-Nr.: am 15. Dezember 2011 an der Fachhochschule Aachen Erstprüfer: Zweitprüfer: Prof. Dr. rer. nat. Bodo Kraft Dipl.-Inf. Arne Rache

2 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.

3 Inhaltsverzeichnis 2 Inhaltsverzeichnis Abstract... 1 Inhaltsverzeichnis Einleitung Was ist Maven? Motivation für Buildmanagement Maven Grundlagen Funktionsweise Lifecycles Plugins POM Repositories Konfiguration Anlegen eines Projektes Erstellen des Projektes Hinzufügen einer Abhängigkeit Weitere Möglichkeiten Vergleich mit Apache Ant Ant Grundlagen Vergleich mit Maven Fazit Zusammenfassung Ausblick Literaturverzeichnis Eidesstattliche Erklärung... 24

4 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 Java- Entwicklern. 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 Build- Funktionalitä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

5 Einleitung 4 beispielsweise mit Hilfe der Plugins automatisiert JavaDocs 1 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 Build- Konzepte. 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 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 Plugin- System Mavens bildet. 1 Automatische Softwaredokumentation des Java-Sourcecodes

6 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 Builds 2 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

7 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 werden

8 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, Artefaktkennung 4 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

9 Funktionsweise 8 vorherigen Build-Vorgangs. Site ist zuständig für die Projektdokumentation. Auf den Default- Lifecycle 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

10 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 Test- Phase 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 Unit- Tests zuständig ist. Es ermöglicht unter anderem JUnit3- und JUnit4-Tests, sowie TestNG-Tests.

11 Funktionsweise 10 Hierbei wurde sehr auf Abwärtskompatibilität geachtet, damit beispielsweise Nutzer von JUnit3- Tests 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.

12 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 HTML- Dokumentationsdate.

13 Funktionsweise 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=" xmlns:xsi=" xsi:schemalocation=" <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> <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.

14 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

15 Funktionsweise 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 Apache 6. 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:

16 Konfiguration Konfiguration Eine Anleitung, wie Maven installiert werden muss, findet sich auf der Maven Homepage 7. 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 (r ; :31: ) Maven home: C:\Program Files\apache-maven 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 Projekten 8, 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

17 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 Artefakt 9 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 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. Kompilieren 9 Vom Nutzer erstelltes, kompiliertes und packetiertes Programm

18 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.

19 Vergleich mit Apache Ant 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

20 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.

21 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.

22 Fazit 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 Jahren 10 immer noch in aktiver Entwicklung, das heißt, dass das noch kontinuierlich neue Funktionen hinzukommen. Momentan ist Maven in der Version 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 Jenkins 12 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 Stand Dezember Webbasiertes System für kontinuierliche Integration für beispielsweise Maven Projekte.

23 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 Ant 13. 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 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 Seit Stand

24 Literaturverzeichnis Literaturverzeichnis Apache Ant Project. (kein Datum). Abgerufen am von Apache Maven Project. (kein Datum). Abgerufen am von Ivy - The agile dependency manager. (kein Datum). Abgerufen am von Jenkins. Abgerufen am von Spiller, M. (2009). Maven 2 Konfigurationsmanagement mit Java. mitp. Thomas Locher, T. O. (kein Datum). Maven Guide. Abgerufen am von

25 Eidesstattliche Erklärung 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 Unterschrift der Studentin / des Studenten