Apache Maven 2.0. Reto Gurtner and Rosmarie Wysseier

Transkript

1 Apache Maven 2.0 Reto Gurtner and Rosmarie Wysseier Berner Fachhochschule - Technik und Informatik (BFH-TI) CH-2501 Biel/Bienne, Schweiz office.ti-bi@bfh.ch, Webseite: Zusammenfassung Diese Arbeit erklärt in einer kurzen Form, was alles zu Maven gehört, und wie man damit arbeitet. Der Schwerpunkt liegt auf der Verwendung von Maven als Buildtool. Um den Einstieg zu erleichtern, werden Beispiele schrittweise erläutert. Dies sowohl anhand der Grundbefehle in der Konsole, als auch mit dem weit verbreiteten Eclipse. Zusätzlich wird die Handhabung mit Versionsverwaltung (Subversion), Subprojekten und einem Buildserver (Maestro) erläutert.

2 2 1 Einführung 1.1 Was ist Maven? Maven wurde von der Apache Software Foundation (ASF) entwickelt, um verschiedene Projekte in derselben Art zu managen. Mit Maven hat jede Art von Projekt denselben Ansatz für den Build Life Cycle. Die Build-Logik kann wieder verwendet werden, und die Arbeitsschritte müssen nicht bei jedem Projekt von Grund auf neu erlernt werden. Damit können sich die Entwickler auf die Erstellung der eigentlichen Funktionalitäten konzentrieren. Die Erklärung, was Maven wirklich ist, gestaltet sich ausserordentlich schwierig. Maven ist eine Technologie für das Projekt-Management, es vereinfacht den Entwicklungsprozess, stellt eine Menge von Standards zur Verfügung, ist ein Repository, ein Framework und Maven ist Software. Nun, in diesem Dokument möchten wir erläutern, wie all diese Punkte ineinander greifen und Maven damit die Software-Entwicklung auf ein anderes Level bringt. [1] 1.2 Was bietet Maven? Maven bietet eine nützliche Abstraktion für die Herstellung von Software. Eigentlich ist das Prinzip dasselbe wie bei einem Auto: Egal wie das Gehäuse und der Motor aussieht, die Benutzung ist bei jedem Auto gleich, die Abläufe sind uns bekannt und ermöglichen, dass wir jederzeit in ein anderes Auto sitzen können. ASF hat sich bei der Entwicklung von Maven dasselbe Ziel gesetzt. Wenn wir wissen, wie ein Projekt mit Maven aufgebaut wird, können wir jederzeit auch an einem anderen Projekt arbeiten. Der Build-Prozess jedes Projekts beinhaltet die Bereitstellung von abhängigen Ressourcen, die Erstellung der Dokumentation, Tests und den eigentlichen Output. Maven macht diesen Prozess weniger zeitraubend und transparenter, weil es standardisierte Projekt-Layouts verwendet und die Abhängigkeiten verwaltet. Die dafür benötigten individuellen Projektstrukturen sind im Project Object Model (POM) deklariert, einer einfachen XML-Datei. Aus der Sicht des Entwicklers ist Maven also ein Tool, das den Build-Prozess vereinfacht und damit Ant ablöst. Maven ist aber nicht einfach ein Ersatz für Ant, sondern wesentlich mehr. Ant stellt keine Konventionen zur Verfügung, alles muss im Build-File angegeben werden, ebenso muss der Ablauf bestimmt werden. Maven kann mit Plugins viele übliche Projekt-Prozesse übernehmen und dies ohne den Aufwand zuerst ein Build-Script zu schreiben.[1] 1.3 Die Vorteile von Maven Logischer Zusammenhang Maven erlaubt jeder Organisation ihre Projekte zu standardisieren und transparenter zu gestalten. Wiederverwendbarkeit Durch die Verwendung von Maven bauen die Projekte auf einer Menge von bewährten Verfahren der Industrie auf.

3 Mobilität Maven senkt die Barriere für die Wiederverwendung der Build-Logik und auch von Software Komponenten. Es ist einfacher Komponenten in ein Projekt zu integrieren. Wartungsfreundlichkeit Das Entwickeln der Builds wird drastisch vereinfacht, der Fokus kann schnell auf die Software Entwicklung gerichtet werden. Weil Maven Projekte einem deniertem Modell folgen, sind sie sehr wartungsfreundlich. Dank all diesen Vorteilen ist es möglich, dass eine eziente Arbeitsteilung und Zusammenarbeit funktioniert und nützliche Code-Stücke wiederverwendet werden können. Die Vereinheitlichung der Prozesse macht die Arbeit für alle am Projekt beteiligten Entwickler einfacher und ezienter. Zudem ist die Chance grösser, dass jemand das Projekt als Ganzes versteht und ein unterhaltbares System resultiert.[1] 1.4 Prinzipien von Maven Hier werden die Prinzipien von Maven kurz erläutert und anhand von Beispielen erklärt. Convention over Conguration: Der Grundsatz von Convention over Conguration wurde von der Ruby On Rails Community 1 geprägt. Um zu verhindern, dass zu viel Zeit für die Konguration eines Projektes aufgewendet wird, denierte man verschiedene Standardkonventionen. Dies bringt viele Vorteile mit sich. Somit erleichtert es zum Beispiel, schneller Applikationen zu errichten oder besser innerhalb von einem Team zu kommunizieren. Nach Denition ist eine Konvention eine Vereinbarung von Standards und Normen. 2 Dies bedeutet, dass man nicht zwangsweise diese Konventionen einhalten muss, es jedoch sehr empfehlenswert ist dies zu tun. [1] Maven kennt drei Konventionen, um eine standardisierte Projektumgebung sicher zu stellen: Standard Directory Layout for Projects The concept of a single Maven project producing a single output Standard naming conventions Standard Directory Layout For Projects: Maven fördert das Verwenden von standardisierten Projektstrukturen. Dies hat den Voteil, dass man sich in neuen Projekten sofort zuerecht ndet, wenn man die Struktur bereits kennt. Entspricht die Standardstruktur nicht dem rmeneigenen Standard, so kann dies natürlich überschrieben werden. Wie bereits erwähnt ist dieses Vorgehen nicht empfehlenswert. Um standardisierte Projektstrukturen zu erstellen, verwendet Maven die sogenannten Archetypes. So kann zum Beispiel eine Projektstruktur für ein klassisches JSP-Projekt automatisch generiert werden. Es gibt eine breite Sammlung von bereits vorgefertigten Archetypes. Zusätzlich hat man die Möglichkeit einen eigenen Archetype zu generieren.[1] 1 Ruby on Rails 2 Wikipedia.de 3

4 4 The concept of a single Maven project producing a single output: Diese Konvention besagt, dass ein einziges Maven-Projekt nur einen Output generieren soll. Man nennt diesen Output auch ein Artifact. Bei grösseren Projekten kommt das Seperation of Concerns (SoC) Prinzip zum Zug. Die Idee hinter diesem Prinzip ist, dass man versucht ein Projekt so aufzutrennen, dass man am Schluss verschiedene unabhängige Teilprojekte hat. Gehen wir zum Beispiel davon aus, dass wir eine 3-Tier Webapplikation haben. Jeder Tier wird in einem eigenem Package repräsentiert. So gibt es die drei Packages: com.test.project.presentation, com.test.project.business und com.test.project.data. Nach dem SoC- Prinzip macht man nun aus diesen Packages drei verschiedene Maven-Projekte. Jedes Projekt generiert einen Output. Beim Business-Tier wäre dies wahrscheinlich ein.jar-file. Dies fördert die Wiederverwendbarkeit und - insbesondere bei Webapplikationen - die Skalierbarkeit.[1] Standard naming conventions: Maven kennt Namenskonventionen für Directories und für Projektoutputs. Wir verdeutlichen dies anhand einer erfundenen Library Super Library, welche sich zum aktuellen Zeitpunkt in der Version 1.5 bendet. Die Konvention besagt nun, dass der Name des.jar-files, welches Maven generiert, super-library-1.5.jar heissen muss. Dies ermöglicht auf einen Blick zu erkennen um welche Library es sich handelt und zusätzlich welche Version vorliegt[1]. Wiederverwenden von Buildlogik: Um gewinnbringende Projekte zu realisieren ist es wichtig, dass man das Rad nicht immer neu ernden muss. Dies gilt insbesondere auch für den Build-Prozess. Gehen wir als Beispiel davon aus, dass wir eine JSP-Webapplikation haben, welche auch CSS-Dateien verwendet. Damit in Produktion eine Webseite möglichst schnell geladen wird, ist es interessant so kleine CSS-Dateien wie möglich zu transferieren. Während der Entwicklung sind so optimierte CSS-Dateien jedoch unleserlich. Wir kreieren also nun eine Applikation, welche uns ein CSS gemäss unseren Wünschen optimiert. Maven durchläuft bei der Generierung eines Artifacts einen sogenannten Build Life Cycle. Dank dem Konzept der Plugins können wir auf jede einzelne Phase des Build Life Cycle Einuss nehmen. Ein Plugin ist somit eine Applikation resp. ein Stück Software, welches in den Build-Prozess integriert werden kann. Wenn wir jetzt also unsere Applikation zum CSS-Optimieren zu einem Maven- Plugin machen, werden die CSS-Dateien jedes mal automatisch optimiert, wenn wir einen Build-Prozess auslösen. Zudem gibt es den weiteren Vorteil, dass wir dank diesem Maven-Plugin unsere Applikation auch für jedes kommende Projekt einfach wiederverwenden können.[1] Declarative Execution: Der Zentrale Punkt in einem Maven-Projekt ist das sogenannte pom.xml. Das POM-File steuert die Ausführungsprozesse von Maven. Dieses Konzept bezeichnet man als declarative execution. Im folgenden veranschaulichen wir das pom.xml, welches die Ausgangslage für jedes Mavenprojekt ist.

5 5 <p r o j e c t> <modelversion> </ modelversion> <groupid>com. mycompany. app</ groupid> <a r t i f a c t I d>my app</ a r t i f a c t I d> <packaging>j a r</ packaging> <version>1.0 SNAPSHOT</ version> <dependencies> <dependency> <groupid>j u n i t</ groupid> <a r t i f a c t I d>j u n i t</ a r t i f a c t I d> <version> </version> <scope>t e s t</ scope> </ dependency> </ dependencies> </ p r o j e c t> Hier eine Beschreibung der wichtigsten XML-Elementen: Project: Ist das root-element des XML's modelversion: Deniert die Version des object model, welches verwendet wird. Diese Angabe ist wichtig, damit Maven richtig funktioniert groupid: Identiziert die Gruppe/Organisation, welche dieses Projekt erstellt hat. (zum Beispiel: ch.bfh.ti.iseminar) artifactid: Repräsentiert den Basisnamen/Projektnamen für das Artifact, welches Maven erstellen wird. Gemäss den standardisierten Namenskonventionen <artifactid>-<version>.<packaging> packaging: Deniert den Packagetype, welcher für dieses Artifact verwendet werden soll. Gültig wäre hier zum Beispiel: JAR, WAR oder EAR. Je nach Packagetyp wird von Maven ein anderer Build Life Cycle verwendet. version: Deniert die Version des Artifacts. Das Wort SNAPSHOT gibt an, dass das Projekt sich noch in der Entwicklungsphase bendet und noch nicht stable ist. Eine Komplette Referenz aller XML-Elemente ndet man unter Einheitliche Organisation von Abhängigkeiten: Wie bereits im vorhergehenden Kapital gesehen, sind im POM viele verschiedene Dinge deniert. Nicht eingegangen wurde auf den Tag <dependencies>. Hier wird jedes Artifact, von welchem das Maven-Projekt abhängig ist, aufgelistet und deniert. Ein Artifact ist in diesem Kontext zu verstehen als ein Stück Software, auf welches Maven zurückgreift. Früher mussten diese Bibliotheken bei jedem Projekt verknüpft werden. Maven erledigt dies nun für uns und sorgt dafür, dass wir dieselben Artifacts nicht mehrmals bei uns abspeichern. Die Artifacts werden deniert durch die groupid, die artifactid, die version und den scope. Was Maven tut ist eigentlich sehr einfach zu erklären: Maven nimmt die angegebenen Abhängigkeitskoordinaten und sucht zuerst im lokalen Repository. Wenn dort

6 6 die entsprechende Version des Artifact noch nicht vorhanden ist, werden remote Repositories durchsucht und das passende Artifact anschliessend im lokalen Verzeichnis abgelegt. Wir müssen also nicht denieren wo die Abhängigkeiten physikalisch zu suchen sind, sondern nur was das Projekt erwartet, dass zur Verfügung steht. Das erwähnte lokale Verzeichnis der Artifacts ist standardmässig unter <user_home>/.m2/repository zu nden. Es ist folgendermassen aufgebaut: Abbildung 1: Die lokale Ablage der Artifacts Bei qualizierten GroupIds (bspw. org.apache.maven) werden die entsprechenden Unterordner erstellt und darin dann die ArtifactId. Das remote Repository ist unter Zusätzlich können noch weitere Remote Verzeichnisse hinzugefügt werden, zum Beispiel für rmeneigene Bibliotheken. Die Reihenfolge des Suchens wird von der Reihenfolge der Denition im pom.xml bestimmt. Dank dieser einheitlichen Handhabung von Abhängigkeiten können mehrere Probleme gelöst werden. So müssen die Entwickler nicht mehr jedes.jar-file im Pfad hinzufügen, die Bibliotheken werden zentral abgelegt, sind nicht mehrfach vorhanden und die Versionsverwaltung wird massiv vereinfacht.[1] 2 Aller Anfang ist schwer 2.1 Ein kleines Projekt - Mit Hilfe der Konsole Installation: Maven kann unter heruntergeladen werden. Unter diesem Link bendet sich zudem eine Installationsanleitung für Maven. Erstellen eines Projektes mittels Archetype: Wenn man ein Maven-Projekt von Grund auf neu erstellen will, macht man dies mit Hilfe des Archetype- Mechanismus. Wie bereits erwähnt ist ein Archetype ein Projekttemplate. Wir starten nun mit dem simpelsten Archetype, denn man verwenden kann. Dazu geben wir auf der Konsole folgenden Befehl ein: C:\my-directory>mvn archetype:create -DgroupId=ch.bfh.ti.iseminar -DartifactId=TestProjekt

7 Parameter Bedeutung mvn Dieses Keyword verwenden wir immer, wenn wir mit Maven arbeiten wollen archetype:create Besagt, dass Maven einen Archetype für die Projekterstellung verwenden soll -DgroupId Hier geben wir die Id unserer Gruppe/Firma/Institution ein -DartifactId Hier denieren wir den konkreten Projektnamen Tabelle 1: Beschreibung der Parameter 7 Nach dem Ausführen dieses Befehls erkennen wir, dass einige Ordner und Dateien angelegt wurden. Dies ist die Standardstruktur für jedes Java-Projekt mit Maven. Um die Vorzüge von Maven etwas mehr auszunutzen wollen wir gemeinsam eine JSP-Applikation erstellen. Auch für diese Aufgabe gibt es einen vorgefertigten Archetype. Wir müssen lediglich den Konsolenaufruf von vorhin etwas erweitern. C:\my-directory>mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=ch.bfh.ti.iseminar -DartifactId=TestProjekt Parameter Bedeutung -DarchetypeGroupId die Group- /FirmenId von dem Archetypeersteller -DarchetypeArtifactId Der Name des konkreten Archetype Tabelle 2: Zusätzliche Parameter für das Verwenden von spezischen Archetypes Eine gute Auistung aller standardmässig vorhandenen Archetypes gibt es unter Selbstverständlich kann man auch weitere Archetypes verwenden, welche von anderen Anbietern zur Verfügung gestellt werden oder sogar eigene Archetypes kreieren. Die Ord-

8 8 nerstruktur die uns Maven nun generiert hat, entspricht tatsächlich jener einer JSP-Webapplikation. Die folgende Abbildung verdeutlicht dies: Abbildung 2: Erstellte Ordnerstruktur Automatischer Build: Um eine Webapplikation auf einen ServletContainer zu deployen, generiert man in der Regel ein sogenanntes.war-file. Um dies mit Ant zu machen, wird ein relativ umfangreiches Ant-Script benötigt. Maven löst dieses Problem viel eleganter. Um dies zu demonstrieren geben wir folgenden Befehl ein: C:\my-directory\TestProjekt>mvn package Anschliessend werden unter C:\my-directory\TestProjekt\target\ verschiedene Ordner mit dem kompilierten Code angelegt. Zudem generiert Maven automatisch ein.war-file: C:\my-directory\TestProjekt\target\TestProjekt.war Hätten wir ein normales Java-Projekt würde dieser Befehl an Stelle von dem.war-file ein.jar-file generieren. Hinzufügen von Dependencies: Eine Webapplikation verwendet oftmals weitere Packages (Dependencies). Ein mögliches Szenario wäre, dass wir die Library log4j hinzufügen möchten. Damit diese Library automatisch bei dem Build hinzugefügt wird, fügen wir dem pom.xml einen neuen dependency-eintrag hinzu. <dependencies> <dependency> <groupid>l o g 4 j</ groupid> <a r t i f a c t I d>l o g 4 j</ a r t i f a c t I d> <version> </version> </ dependency> </ dependencies>

9 Beim Build-Prozess schaut Maven ob die log4j-library in unserem lokalen Repository verfügbar ist. Ist dies der Fall, so wird auch diese Library automatisch in das generierte.war-file eingebunden. Ist die Library noch nicht in unserem lokalen Repository verfügbar, so kopiert Maven die Library zuerst von dem default global Repository ( in unser lokales Repository. Es kann natürlich auch passieren, dass die gewünschte Library nicht in dem default global Repository vorhanden ist. Zum Beispiel wenn es sich um eine rmeneigene Library handelt. Zum Teil sind auch prominentere Libraries nicht in dem default global Repository vorhanden. Ein Beispiel dafür sind die Libraries von Hibernate 3. Diese sind in einem anderen globalen Repository zu nden. Damit man nun diese Libraries trotzdem mit dem Dependencies-Management verwenden kann, gibt es die Möglichkeit weitere Adressen für globale Repositories zu denieren. Wir machen dies auch wieder im pom.xml <p r o j e c t> <r e p o s i t o r i e s> <r e p o s i t o r y> <i d>bfh maven repo1</ i d> <name>bfh maven repo1</name> <u r l>h t t p : // repo1. bfh. h t i. ch/maven2</ u r l> </ r e p o s i t o r y> </ r e p o s i t o r i e s> </ p r o j e c t> Maven durchsucht somit das default global Repository und zusätzlich all diejenigen, welche unter <repositories> speziziert wurden. Verwenden von Plugins: Eine Webapplikation will man in der Regel auf einen ServletContainer deployen. Bekannte Beispiele hierfür sind der Apache Tomcat 4 oder Jetty 5. Es existieren unterschiedliche Plugins für die verschiedenen Phasen des Build Life Cycle. Da die Integration von Jetty wesentlich ausgereifter ist als die Integration von Tomcat, zeigen wir hier die Integration von Jetty. Das Maven Jetty Plugin ermöglicht die Webapplikation direkt in Maven laufen zu lassen. Damit dies funktioniert müssen wir das Plugin in unser pom.xml einbinden.[2] <p r o j e c t> <build> <finalname>testprojekt</ finalname> <plugins> <plugin> <groupid>org. mortbay. j e t t y</ groupid> 3 Hibernate 4 Tomcat 5 Jetty 9

10 10 <a r t i f a c t I d>maven jetty plugin</ a r t i f a c t I d> </ plugin> </ plugins> </ build> </ p r o j e c t> Um diese Webapplikation nun auszuführen muss man lediglich folgenden Befehl eingeben: C:\my-directory\TestProjekt>mvn jetty:run Nach diversen Downloads wird Jetty automatisch gestartet. Rufen wir nun in einem Webbrowser folgende Adresse auf erscheint ein Hello World, welches aus dem index.jsp von unserer Webapplikation resultiert. Die Url ergibt sich aus dem Element <finalname> von dem pom.xml[2] Automatische Tests mit JUnit: Damit man bei einer Webapplikation überhaupt JUnit-Tests 6 ausführen kann, benötigt man auch Java-Klassen. Bis jetzt wurde nicht diskutiert wo diese Klassen hinkommen. Der Archetype, welchen wir verwendet haben, generiert den Zielordner der für den Java-Source gilt nicht automatisch. Also müssen wir dies als erstes manuell machen. Dazu geben wir den folgenden Befehl auf der Konsole ein[2]: C:\my-directory\TestProjekt>mkdir src\main\java Wie wir aus dem Kommando erkennen können werden die Java-Sources in Maven immer in dem Ordner src\main\java platziert. Was ist nun aber mit den Test-Sources? Allgemein gilt, dass alles was mit Tests zu tun hat in dem Ordner src\test platziert wird. Im Fall von JUnit-Testklassen ist dies also in src\test\java. Da auch dieser Ordner nicht automatisch von unserem Archetype erstellt wurde, machen wir dies ebenso manuell: C:\my-directory\TestProjekt>mkdir src\test\java Besondere Beachtung müssen wir noch der Dependency-Angabe von JUnit schenken. Den von uns verwendete Archetype hat hier automatisch JUnit eingebunden. Wir möchten dies nun auf Version 4.5 ändern. Damit Maven dies berücksichtigt müssen wir lediglich die Versionsnummer in der Dependency anpassen: <dependencies> <dependency> <groupid>j u n i t</ groupid> 6 JUnit

11 <a r t i f a c t I d>j u n i t</ a r t i f a c t I d> <version>4. 5</ version> </ dependency> </ dependencies> Würden wir nun die Tests ausführen, würde einen Fehler produziert. Das Problem liegt darin, dass Maven beim Kompilieren standardmässig Java 1.3 konformer JavaCode verlangt. Da aber JUnit 4 zum Beispiel Annotations verwendet, welche in Java 1.3 noch nicht unterstützt waren, führt dies zu einem Fehler. Um diesen zu beheben, muss man im pom.xml angeben, dass man Java 1.6 konformer JavaCode produzieren will. Man macht dies durch das Einbinden des folgenden Plugins: [2] <build> <plugins> <plugin> <a r t i f a c t I d>maven compiler plugin</ a r t i f a c t I d> <c o n f i g u r a t i o n> <source>1.6</ source> <t a r g e t>1.6</ t a r g e t> </ c o n f i g u r a t i o n> </ plugin> </ plugins> </ build> Nun können wir die Tests automatisch ausführen lassen mittels folgendem Konsolebefehl: C:\my-directory\TestProjekt>mvn test Automatische Dokumentation: Ein Qualitätsmerkmal eines guten Projektes ist auch eine gute Dokumentation. Maven hat auch für dieses Problem eine elegante Lösung bereit. Mittels eines ganz einfachen Befehl erstellt Maven eine Webseite, welche eine Projektdokumentation enthält. Der Inhalt für diese Webseite wird zum Teil über das pom.xml gesteuert. Für das Generieren einer standardisierten Projektwebsite geben wir folgenden Befehl auf der Konsole ein: C:\my-directory\TestProjekt>mvn site Im Ordner C:\my-directory\TestProjekt\target\site bendet sich die generierte Website. Wir können diese Webseite noch selber erweitern indem wir im Ordner C:\my-directory\TestProjekt\src einen neuen Ordner namens site erstellen und alle benötigten HTML-Files usw. darin platzieren. Zudem sollte man in diesem Ordner ein sogenannten SiteDescriptor anlegen site.xml. [1] Eine detailliertere Beschreibung für das individuelle Gestalten der Projektseite gibt es unter 11

12 12 Umwandeln in ein Eclipse-Projekt: Ein bereits auf der Konsole erstelltes Projekt kann jederzeit in ein Eclipse-Projekt umgewandelt und in Eclipse importiert werden. Dafür verwenden wir den Befehl: C:\my-directory\TestProjekt>mvn eclipse:eclipse 2.2 Ein kleines Projekt - mit Hilfe des Eclipse-Plugins m2eclipse Installation: Zusätzlich zum bereits im letzten Kapitel installierten Maven muss nun im Eclipse 7 das Maven-Eclipse-Plugin installiert werden. Der Link, welcher im Update-Manager von Eclipse eingegeben werden muss lautet: Sobald der Server geladen ist, werden drei Gruppen von Eclipse-Plugins angezeigt. Für unseren Zweck installieren wir Maven Integration und unter Maven Project Congurators den Punkt Maven Integrators for WTP. Nach der Installation muss Eclipse neu gestartet werden. Erstellen eines Projektes mittels Archetype: Nun versuchen wir das bereits im letzten Kapitel erstellte Projekt im Eclipse nachzubilden. Um ein Maven-Projekt im Eclipse zu erstellen wählen wir New>Other, anschliessend Maven Project und Next. Bei der nächsten Anzeige können wir nur Use default Workspace Location auswählen und dann wiederum Next klicken. Nun können wir hier ein Archetype auswählen, dazu muss der Katalog Internal aktiviert werden. Im nächsten Schritt geben wir die GroupId und die ArtifactId ein und drücken Finish. Automatischer Build: Dies geht, wie auch auf der Konsole, sehr einfach. Wir machen einen Rechtsklick auf das Projekt und wählen Run As>Maven Package. Beim ersten Mal kann dies schon etwas dauern, da die Packages heruntergeladen werden müssen. Wie bereits zuvor können wir nun im target-folder das Resultat überprüfen und nden an dieser Stelle das erwünschte.war-file, wie wir dies für eine JSP-Applikation benötigen. Hinzufügen von Dependencies: Dies kann natürlich auch über die Erweiterung des pom.xml-file geschehen, aber es gibt auch ein benutzerfreundliches GUI. Dafür klicken wir wiederum mit der rechten Maustaste auf das Projekt und wählen Maven>Add Dependency. Dort können wir nun eine Eigenschaft des gewünschten Artifacts eingeben. Dabei spielt es keine Rolle ob wir nach GroupId oder ArtifactId suchen. Für die im vorangehenden Kapitel erwähnten rmeneigenen Libraries erfassen wir nun noch das Repository. Dazu önen wir das pom.xml-file und wählen bei den Reitern unten Repositories. Nun klicken wir auf Add.., geben unsere Angaben ein und speichern die Datei. Eine Eingabemaske wie diese gibt es auch für die Plugins und Dependencies. Dazu 7 Eclipse Foundation

13 klicken wir einfach auf den entsprechenden Reiter. Nun erfassen wir noch das Jetty-Plugin. Dazu machen wir wiederum einen Rechtsklick auf dem Projekt und wählen Maven>Add Plugin. Dort suchen wir nach Jetty und fügen das Plugin hinzu. Nun können wir jetty:run ausführen. Leider gibt es hierfür kein Menü, wir wählen dazu nach dem Rechtsklick auf das Projekt Run As>Maven' Build... und geben unter Goals jetty:run ein. Danach klicken wir auf Run und sollten dasselbe Resultat erhalten wie vorhin ohne das Eclipse-Plugin und können unser Projekt im Browser önen. Automatische Tests mit JUnit: Im Eclipse müssen wir, wie bereits auf der Konsole zuerst die Java-Ordner erstellen. Dazu machen wir einen Rechtsklick auf dem Java Resources : resources-ordner und wählen New>Source Folder. Dort geben wir den Projektnamen ein und als Folder Name src/main/java und drücken Finish. Dasselbe machen wir für src/test/java. Nun können wir wie auf der Konsole Maven-Tests sehr schnell durchführen. Dazu machen wir wiederum einen Rechtsklick auf das Projekt und wählen Run As>Maven test. Automatische Dokumentation: Die Dokumentation erstellen wir im Eclipse ähnlich wie wir jetty:run ausgeführt haben über Run As>Maven build.. und geben unter Goals site ein und klicken Run. 3 Managen von Projekten 3.1 Integration mit Subversion Auf der Konsole: Maven stellt ein SCM 8 -Plugin zur Verfügung. Damit dies funktioniert müssen wir im pom.xml einige Anpassungen machen.[3] Nebst der Integration von SVN werden von SCM noch zusätzliche Dienste unterstützt: In einem ersten Schritt müssen wir das SCM kongurieren. Wir machen dies, indem wir dem pom.xml das Element <scm> hinzufügen. Wichtig: <scm> ist ein direktes Kind von <project>. <p r o j e c t> <scm> <connection> s c m : s v n : h t t p : // user:password@svn. bfh. ch/ isem / TestProjekt / trunk </ connection> <developerconnection> s c m : s v n : h t t p : // user:password@svn. bfh. ch/ isem / TestProjekt / trunk </ developerconnection> </scm> </ p r o j e c t> 8 Source Control Management 13

14 14 Bei der Connection geben wir die URL zu unserem SVN-Repository ein. Analog machen wir dies für developerconnection. Falls ein lokaler SVN verwendet werden soll, könnte unsere URL so aussehen: 'le://localhost/c:/mysvn/isem/testprojekt/trunk/pom.xml'. Des weiteren wird noch ein Plugin benötigt, welches wir pro Connection einzeln angeben müssen. <plugins> <plugin> <groupid>org. apache. maven. plugins</ groupid> <a r t i f a c t I d>maven scm plugin</ a r t i f a c t I d> <version>1. 0</ version> <c o n f i g u r a t i o n> <connectiontype>connection</ connectiontype> </ c o n f i g u r a t i o n> </ plugin> <plugin> <groupid>org. apache. maven. plugins</ groupid> <a r t i f a c t I d>maven scm plugin</ a r t i f a c t I d> <version>1. 0</ version> <c o n f i g u r a t i o n> <connectiontype>developerconnection</ connectiontype> </ c o n f i g u r a t i o n> </ plugin> </ plugins> Nun ist unser Projekt vorbereitet. Bevor wir aber Maven mit dem SCM- Plugin verwenden können, sollten wir die Dateien mit einem externen SVN- Client hinzufügen. [3] Wenn nun alles richtig konguriert ist und die Dateien alle hinzugefügt wurden, können wir den Test machen. Dazu navigieren wir auf Konsole in unseren Projekt-Ordner und geben folgenden Befehl ein: mvn scm:validate Damit kontrollieren wir die Angaben im pom.xml. In der Konsole müsste am Schluss Build successful stehen, dann funktioniert alles. Um unser Projekt zu aktualisieren verwenden wir den Befehl: mvn scm:update Nun verändern wir eine Datei und möchten diese ebenfalls über die Konsole wieder übertragen. Dafür verwenden wir folgenden Befehl: mvn -Dmessage="<Beschreibung der Änderung>" scm:checkin Weitere Befehle und deren genaue Bedeutung nden wir unter:

15 Mit Eclipse: Um dieselbe Funktionalität in Eclipse zu verwenden gibt es mehrere Möglichkeiten. Wir können, ohne ein weiteres Plugin zu installieren, dieselben Befehle wie auf der Konsole ausführen. Dafür klicken wir mit der rechten Maustaste aufs Projekt und wählen, genau so wie bereits beim jetty-plugin, Run As>Maven build.., geben unter Goals den Befehl ein und klicken auf Run. (Befehl ohne mvn) Es gibt auch für die SVN-Integration eine andere Lösung. Dafür gibt es mehrere Eclipse-Plugins. Wir haben uns für Subclipse entschieden. Die URL für den Update-Manager von Eclipse lautet: Nun önen wir Window>Preferences, önen den Eintrag Team und wählen SVN. Anschliessend erscheint eine Fehlermeldung. Diese können wir bestätigen und stellen dann das SVN-Interface auf SVNKit (Pure Java). Danach klicken wir OK. Als erstes müssen wir unser SVN-Repository angeben. Dafür önen wir Window>Open Perspective>Other... und im erscheinenden Fenster SVN Repository Exploring. In dieser neuen Ansicht können wir in der linken Spalte rechts klicken und wählen dort New>Repository Location. Nun können wir unsere Repository-URL angeben und werden mittels Pop-Up zur Eingabe des Passwortes aufgefordert. Anschliessend erscheint die Ordner-Struktur in der linken Spalte. Dort suchen wir den trunk-ordner unseres Projektes und machen darauf einen Rechtsklick und wählen Checkout. Jetzt können wir einen Projektnamen und die Version wählen. Falls wir nicht im aktuellen Workspace arbeiten möchten, können wir auch mit Next dies noch anpassen. Anschliessend drücken wird Finish. Das Projekt wird nun in unseren Workspace importiert. Jetzt wechseln wir wieder die View. Für unser Beispiel wäre dies Window>Preferences>Other... und Web. Dort sehen wir unser Maven-Projekt. Die SVN-Befehle nden wir jeweils mittels Rechtsklick auf dem Projekt und Team Arbeiten mit Subprojekten Wie unter dem Abschnitt Convention over Conguration im Kapitel 1.4 Prinzipien von Maven beschrieben, macht es Sinn grössere Projekte in Subprojekte zu unterteilen. Maven stellt einen Ansatz zur Verfügung, damit diese Subprojekte trotzdem zentral gemanaged werden können. Die Idee ist, dass man aus den verschiedenen Subprojekten sogenannte Module und, für das Handling aller Module, ein sogenanntes Multi-module Project macht. Gehen wir nun als Beispiel davon aus, dass wir eine Webapplikation haben, die in zwei Module aufgeteilt wurde: com.test.coolapplication.presentation und com.test.coolapplication.business. Als dritten Aspekt benötigen wir noch ein sogenanntes Parent-Project, welches die Module enthält: com.test.coolapplication [2] Das Parent-Project: Als erstes werfen wir einen Blick auf das Parent-Project. Dieses enthält ein pom.xml: <p r o j e c t>

16 16 <modelversion> </ modelversion> <groupid>com. t e s t</ groupid> <a r t i f a c t I d>c o o l a p p l i c a t i o n</ a r t i f a c t I d> <packaging>pom</ packaging> <version>1. 0</ version> <name>parent Project f o r our Topapplication</name> <modules> <module>business</module> <module>p r e s e n t a t i o n</module> </ modules> <dependencies> <dependency> <groupid>j u n i t</ groupid> <a r t i f a c t I d>j u n i t</ a r t i f a c t I d> <version>4. 5</ version> <scope>t e s t</ scope> </ dependency> </ dependencies> </ p r o j e c t> Ein interessanter Punkt ist, dass dieses Parent-Project kein.jar-file oder ein anderes Package erstellt. Der Eintrag pom als <packaging> deniert, dass dieses pom.xml andere Maven-Projekte referenziert. Unter <modules> werden alle Module angegeben. Jedes Modul referenziert ein Subdirectory relativ zum Parent-Project. Konkret heisst das, dass es im Ordner coolapplication zwei Ordner namens presentation und business gibt. Da wir die Logik vom Business-Tier in dem Presentation-Tier verwenden wollen, müssen die Module in dieser bestimmten Reihenfolge deniert werden. Alles was nach <modules> angegeben wird, wird von den Subprojekten geerbt. Das heisst konkret, dass com.test.coolapplication.presentation und com.test.coolapplication.business automatisch die dependency junit beinhalten.[2] Die Subprojekt / Module: In den Subprojekten müssen wir nun noch angeben, welches das entsprechende Parent-Project ist. Wir schauen uns zuerst das Modul: com.test.coolapplication.business an. Die Anpassungen werden natürlich auch im pom.xml vorgenommen: <p r o j e c t> <modelversion> </ modelversion> <pa rent> <groupid>com. t e s t</ groupid> <a r t i f a c t I d>c o o l a p p l i c a t i o n</ a r t i f a c t I d> <packaging>j a r</ packaging>

17 17 <version>1. 0</ version> </ parent> <groupid>com. t e s t. c o o l a p p l i c a t i o n</ groupid> <a r t i f a c t I d>b usiness</ a r t i f a c t I d> <packaging>j a r</ packaging> <version>1. 0</ version> <name>business Tier of our Project</name> </ p r o j e c t> Innerhalb des Elements <parent> geben wir nun die Referenzierung zu unserem Parent-Project an. Im zweiten Modul, com.test.coolapplication.presentation, möchten wir zusätzlich noch die Klassen von dem Business-Tier, com.test.coolapplication.business, ansprechen. Nachfolgend zeigen wir, wie das pom.xml von com.test.coolapplication.presentation aussehen muss: <p r o j e c t> <modelversion> </ modelversion> <pa rent> <groupid>com. t e s t</ groupid> <a r t i f a c t I d>c o o l a p p l i c a t i o n</ a r t i f a c t I d> <packaging>war</ packaging> <version>1. 0</ version> </ parent> <groupid>com. t e s t. c o o l a p p l i c a t i o n</ groupid> <a r t i f a c t I d>p r e s e n t a t i o n</ a r t i f a c t I d> <packaging>j a r</ packaging> <version>1. 0</ version> <name>presentation Tier of our Project</name> <dependencies> <dependency> <groupid>com. t e s t. c o o l a p p l i c a t i o n</ groupid> <a r t i f a c t I d>b usiness</ a r t i f a c t I d> <version>1. 0</ version> </ dependency> </ dependencies> </ p r o j e c t> Wir erkennen, dass man das andere Modul wie eine ganz normale dependency in com.test.coolapplication.presentation einbinden kann.[2] Builden eines Multimodule-Project: Um jetzt das gesamte Projekt zu builden müssen wir auf der Konsole folgenden Befehl eingeben: C:\my-directory\coolapplication>mvn clean install

18 18 Maven führt nun folgende Schritte aus: 1. Maven lädt das pom.xml des Parent-Project und alloziert die pom.xml's von allen Modulen 2. Maven übergibt alle pom.xml's dem Maven Reactor 3. Der Maven Reactor analysiert die Abhängigkeiten zwischen den einzelnen Modulen und stellt sicher, dass alle Module in der richtigen Reihenfolge kompiliert werden 4. Maven führt für jedes Modul, in der richtigen Reihenfolge, ein mvn clean install aus. Mit Hilfe des gleichen Vorgehens können auch andere Maven-Befehle ausgeführt werden.[2] 3.3 Automatischer Build-Prozess mit Buildserver (Maestro) Ein Buildserver hat die Fähigkeit in einem gewissen Zeitintervall immer wieder einen neuen Build unseres Projektes anzulegen. Man spricht dabei auch von Continuous Integration. Nebst dem, dass der Buildserver den automatischen Build übernimmt, hat er in der Regel auch noch andere Fähigkeiten. So kann er zum Beispiel auch Tests ausführen, Dokumentationen generieren und die Entwickler benachrichtigen, wenn irgend etwas fehlschlagen sollte. Das Verwenden von regelmässigen Buildzyklen kann den Entwicklungsprozess positiv beeinussen. Oft wählt man die Buildzyklen so, dass jede Nacht ein neuer Build angelegt wird. Man spricht dabei auch von einem Nightly-Build. Auch kürzere Zeitabstände zwischen den Zyklen können Sinn machen. So wir durch Continuous Integration eine bessere Entwicklungskultur unterstützt, und die Teams können Änderungen in kleineren Iterationen vornehmen.[1] Wir zeigen nun die Verwendung des Buildservers Maestro von Exist 9. Wichtig ist zu sagen, dass in diesem Dokument nicht beschrieben wird, wie man Maestro installiert und konguriert. Wir fokussieren uns nur auf die Verwendung von Maestro im Zusammenhang mit Maven 2.0. Für unsere Dokumentation verwendeten wir die Version 1.5 von Maestro.[1] Aufnehmen eines neuen Projektes: Damit Maestro ein Maven-Projekt verwalten kann, muss dieses Maven-Projekt auf einem SVN-Repository hinterlegt werden. Damit alles reibungslos funktioniert, sollte sich dieses Projekt in einem sogenannten trunk Ordner benden. Zudem sollte das pom.xml ein direktes Kind vom Ordner trunk sein. Also: trunk\pom.xml. Das SVN-Repository sollte über eine URL erreichbar sein (z.b. ' oder sich auf der gleichen Maschine wie der ServletContainer von Maestro benden. Bevor wir das Projekt registrieren können, müssen wir in unserem pom.xml diverse Anpassungen vornehmen. Wie man den SVN-Zugang über Maven realisiert wurde bereits unter 3.1 Integration mit Subversion beschrieben. Als nächsten Schritt müssen wir ein Element cimanagement hinzufügen. 9 Exist

19 <p r o j e c t> <cimanagement> <system>continuum</ system> <u r l>h t t p : // l o c a l h o s t : /continuum</ u r l> <n o t i f i e r s> <n o t i f i e r> <type>mail</ type> <c o n f i g u r a t i o n> <address>dummy@bfh. ch</ address> </ c o n f i g u r a t i o n> </ n o t i f i e r> </ n o t i f i e r s> </ cimanagement> </ p r o j e c t> Unter dem Element <url> geben wir die URL von unserer Maestro Webapplikation an. Als Kinder des Elementes <notifiers> können verschiedene Systeme angegeben werden, die bei Problemen benachrichtigt werden sollen. In unserem Beispiel würde eine an dummy@bfh.ch gesendet. Durch das Hinzufügen eines weiteren <notifier>-eintrags, können weitere -Adressen angegeben werden.[1] Nun können wir noch ein <distributionmanagement>-element hinzufügen. Darin können wir angeben wohin die Site, welche das Projekt dokumentiert, deployed werden soll. Zum Beispiel könnte Maestro nach jedem Build, die Webseite mit der Projektdokumentation in einen Tomcat deployen.[1] <p r o j e c t> <distributionmanagement> <s i t e> <id>website</ id> <u r l> f i l e : // l o c a l h o s t /C:/Tomcat6/webapps/ TestProjekt / s i t e </ u r l> </ s i t e> </ distributionmanagement> </ p r o j e c t> Bevor wir mit Maestro arbeiten können, benötigen wir noch ein Plugin. Dazu fügen wir folgende Plugin-Denition in unserem pom.xml hinzu: <p r o j e c t> <plugins> <plugin> <a r t i f a c t I d>maven s i t e plugin</ a r t i f a c t I d> <c o n f i g u r a t i o n> 19

20 20 <l o c a l e s>en</ l o c a l e s> </ c o n f i g u r a t i o n> </ plugin> </ plugins> </ p r o j e c t> Nun endlich beginnt die eigentliche Arbeit mit Maestro. Um nun ein neues Projekt zu registrieren, müssen diverse Schritte ausgeführt werden. Als erstes müssen wir uns auf dem Webinterface von Maestro einloggen. Sobald wir eingeloggt sind, müssen wir im Hauptmenü oben rechts auf Build Management klicken. Abbildung 3: Auswählen von Build Management im Hauptmenü des Maestro Webinterfaces In dem neu erschienenen Dialog bekommt man eine Übersicht über alle Project Groups. Wir wählen nun die Project Group, zu welcher wir unser Projekt hinzufügen wollen. Wir machen dies indem wir auf den Namen der Project Group klicken. Anschliessend erscheint eine neue Seite, welche eine Übersicht über alle Projekte zeigt, die sich bereits in dieser Project Group benden. Unter der Sparte Group Actions bendet sich eine Schaltäche add. Diese klicken wir um ein neues Projekt hinzuzufügen. Bevor wir dies tun, müssen wir aber sicherstellen, dass in der DropDown-Box Add M2 Project selektiert ist. Abbildung 4: Klicken auf add für das Hinzufügen eines neuen Projektes In dem neuen Dialog können wir nun die URL zu unserem pom.xml von dem Projekt eingeben. Wenn sich das Projekt auf einem SVN bendet, der über HTTP zugänglich ist, können wir diese URL eingeben (z.b. ' Anders funktioniert es, wenn das Projekt sich auf einem SVN bendet, welcher auf der gleichen Maschine installiert ist wie der ServletContainer von Maestro. In diesem Fall könnte unsere URL so aussehen: 'le://localhost/c:/mysvn/ti/iseminar/testprojekt/trunk/pom.xml'.

21 21 Abbildung 5: Eingabemaske für das Hinzufügen eines neuen Projektes Falls Subversion eine Authentizierung verlangt, müsste diese Angaben unter den Feldern Username und Password angegeben werden. Anschliessend klicken wir unten links auf die Add Schaltäche. In der Übersicht unserer Project Group sollte nun das neue Projekt vorhanden sein. Der Namen des Projektes entspricht der Denition im pom.xml. Abbildung 6: Das neue Projekt wurde erfolgreich hinzugefügt

22 22 Manuelles Starten eines Build: Um manuell einen Build zu starten, klickt man - in der Übersicht der entsprechenden Project Group - auf das Icon Build Now des gewünschten Projektes: Abbildung 7: Manuelles Starten eines Builds Durch Klick auf den Projektnamen (TestProjekt Maven Webapp) kommt man auf die Projektübersichtsseite. Klickt man auf dieser Seite auf den Tab Builds, bekommt man eine Übersicht über alle Builds die ausgeführt wurden. Durch ein Klick auf den Link Result, kann man die Resultate ansehen. Wenn ein Build gerade ausgeführt wird, kann man den Vorgang auf der Result-Seite mitverfolgen. Abbildung 8: Übersicht über alle Builds