Seminar - Bericht. Maven Project Management & Comprehension. Fachhochschargau Departement Technik Studiengang Informatik. Gruppe Jonas Weibel

Transkript

1 Seminar - Bericht Maven Project Management & Comprehension Fachhochschargau Departement Technik Studiengang Informatik Gruppe Jonas Weibel Betreuender Dozent Prof. Dr. Dominik Gruntz Windisch, im Januar 2006

2 Inhaltsverzeichnis 0 EINFÜHRUNG GRUNDLAGEN POM.XML (PROJECT OBJECT MODEL) FILESTRUKTUR DER LEBENSZYKLUS EINES PROJEKTS REPOSITORIES LEBENSZYKLUS DETAILLIERT PLUGINS ECLIPSE SITE JDEPEND TRANSITVE ABHÄNGIGKEITEN PLUGINS VS. ABHÄNGIGKEITEN VARIABLEN ZUR LAUFZEIT DOKUMENTATION BIBLIOGRAPHIE ABBILDUNGSVERZEICHNIS ANHANG KOMPLETTES POM EHRLICHKEITSERKLÄRUNG Seite 2 von 17

3 0 Einführung Maven wurde ursprünglich entwickelt um den Entwicklungsprozess des Jakarta Turbine Projektes zu vereinfachen. Dieses Software-Projekt beinhaltete viele Teilprojekte, welche teilweise nur geringe Unterschiede aufwiesen. Das Projektteam suchte nach einer Lösung, bei der der Aufbau und Ablauf des Projektes standardisiert und die Bestandteile definiert sind. Maven ist ein Project Management & Comprehension Tool für Java Softwareprojekte. Als solches formuliert es den Ablauf eines Softwareprojektes klar, definiert eine feste Struktur und vereinfacht somit die ganze Entwicklung von Software. In einer zentralen xml Datei sind alle Informationen des Projektes abgespeichert. Dieses so genannte Object Model ist sehr mächtig und definiert die Struktur sowie Eigenschaften des Softwareprojektes. Alle Maven Projekte durchlaufen fix vorgeschriebene Phasen. Von der Validierung über das Kompilieren des Quellcodes bis hin zum Auswerten von Tests verfügt dieser als Lebenszyklus bekannte Ablauf über die gängigsten Softwareentwicklungsphasen. Die einzelnen Phasen lesen aus dem Object Model und verhalten sich dementsprechend. Mit Plugins, die ebenfalls der Java Sprache unterliegen, können jeder Lebensphase verschiedene Aktionen zugewiesen werden und so zu bestimmten Zeitpunkten im Projekt spezifisches Verhalten vorgegeben werden. Mit Plugins lassen sich basierend auf dem Object Model ausführliche Maven- Dokumentationen erstellen. Zuerst werden in diesem Bericht grundlegende Elemente eines Maven Projektes eingeführt. Allen voran das Object Model. Der Lebenszyklus, der als nächstes erörtert wird, ist eng mit Plugins verbunden, von denen ich zwei vertiefe. Ein weiteres habe ich zur Anbindung an eine JDepend Testauswertung selbst entwickelt. Als letztes Kapitel wird mit Abhängigkeiten eine zentrale Eigenschaft eines Projektes vertieft, die ebenfalls Teil des Object Model ist. Im Anhang ist ein komplettes Object Model angefügt. Dieses soll zeigen, wo und wie die einzelnen Eigenschaften ins Object Model integriert werden. Maven ist interessant für ein Softwareentwicklungsteam, das in einer Java Umgebung arbeitet. Dieses Dokument bietet eine technische Einführung in dieses Tool. 1 Grundlagen Nach der Installation von Maven kann man bereits ein Projekt erzeugen. Dabei wird zum einen ein pom.xml File erzeugt und zum anderen eine Standard- Dateistruktur angelegt, die durch das gesamte Projekt bestehen bleibt. Seite 3 von 17

4 1.1 pom.xml (Project Object Model) Diese Datei liegt im Rootverzeichnis des Projektes. Sie ist das Basis Werkzeug in Maven und beinhaltet das so genannte Object Model eines Projects. Direkt nach der Erstellung eines Projektes sieht diese XML- Datei folgendermassen aus: <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> Project Top-level element in allen Maven Projects modelversion Version des Object Model groupid Eindeutige Bezeichnung des Projektteams (typischerweise kompletter domain name der Organisation) artifactid Bestandteil des Projektnamens: <artifactid>-<version>.<ext> packaging In welches Format soll das Produkt während dem Lebenszyklus gepackt werden? (z.b. jar, war, ear, ) Version Version des Produktes Name voller Projektnamen (wird z. B. für die automatisch generierte Maven Dokumentation verwendet.) url URL zum Projekt (wird z. B. für die automatisch generierte Maven Dokumentation verwendet.) description Beschreibung zum Projekt (wird z. B. für die automatisch generierte Maven Dokumentation verwendet.) Dependencies Abhängigkeiten des Projektes (siehe Kapitel 4) Seite 4 von 17

5 1.2 Filestruktur my-app -- pom.xml -- src -- main `-- java `-- com `-- mycompany `-- app `-- App.java `-- test `-- java `-- com `-- mycompany `-- app `-- AppTest.java `-- target -- classes `-- com `-- mycompany `-- app `-- App.class -- test-classes `-- com `-- mycompany `-- app `-- AppTest.class `-- my-app-1.0-snapshot.jar Java source code Unit test Das Target Verzeichnis beinhaltet diverse Output Dateien des Projektes: class files jar files ev. Dokumentationen 2 Der Lebenszyklus eines Projekts Die Maven-Entwickler sind davon ausgegangen, dass jeder Build-Prozess bestimmte Phasen durchläuft. Man kann daher von einem definierten Ablaufschema sprechen. Die Tabelle Phasen des Build-Zyklus zeigt die zur Verfügungen stehenden Stufen, die zusammengefasst als Lebenszyklus bezeichnet werden. Jeder Phase können Funktionen auch Plug-ins genannt zugeordnet werden. Diese arbeitet Maven zur Laufzeit des Build entlang des Lebenszyklus ab. Seite 5 von 17

6 Phasen des Build-Zyklus: validate generate-sources process-sources generate-resources process-resources compile process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile test package before-integration-test integration-test after-integration-test verify install deploy validate the project is correct and all necessary information is available. generate any source code for inclusion in compilation. process the source code, for example to filter any values. generate resources for inclusion in the package. copy and process the resources into the destination directory, ready for packaging. compile the source code of the project. post-process the generated files from compilation, for example to do bytecode enhancement on Java classes. generate any test source code for inclusion in compilation. process the test source code, for example to filter any values. create resources for testing. copy and process the resources into the test destination directory. compile the test source code into the test destination directory run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed. take the compiled code and package it in its distributable format, such as a JAR. perform actions required before integratiob tests are executed. This may involve things such as setting up the required environment. process and deploy the package if necessary into an environment where integration tests can be run. perform actions required after integration tests have been executed. This may including cleaning up the environment. run any checks to verify the package is valid and meets quality criteria. install the package into the local repository, for use as a dependency in other projects locally. done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects. Fett gedruckte Phasen gelten als die üblichsten und meist angewendeten. Seite 6 von 17

7 2.1 Repositories Dieses Unterkapitel beschreibt die Lebensphasen install und deploy. Sie arbeiten mit den so genannten Repositories zusammen, wo Software anderen Programmen auf dem lokalen Computer (local Repository) und anderen Entwicklern (remote Repository) zugänglich gemacht wird. Abbildung 1: Maven Repositories Eigene Remote Repositories werden im POM definiert. Implizit erreicht Maven das Remote Repository von Apache. 2.2 Lebenszyklus detailliert Ein Lebenszyklus wird mit dem Befehl mvn gestartet. So wird zum Beispiel der Source mit mvn compile kompiliert. Man beachte, dass dieser Befehl auch alle vorgängigen und noch nicht ausgeführten Lebenszyklen vorgängig ausführt. mvn clean ist ein Befehl, der das target Verzeichnis entfernt. mvn clean install löscht das target Verzeichnis und führt den install-lebenszyklus durch (sowie dessen Vorgänger) Seite 7 von 17

8 Zusammenfassung Beim Lebenszyklus wird der Build Prozess durchlaufen. Abbildung 2: Maven 2 Lebenszyklen Dieser wird zum einen von den Informationen der pom.xml Datei beeinflusst und zum anderen können individuelle Plugins den Projektphasen spezifisch angehängt werden. Sinn des nächsten Kapitels ist es letztere Variante zu beschreiben. 3 Plugins Es gibt unzählige Plugins, die von Apache zur Verfügung gestellt werden ( Im Folgenden gehe ich auf zwei Plug-ins davon ein (eclipse, site) und erstelle eines selbst (JDepend). Die nächsten Kapitel zeigen Ideen wie und wann (Lebenszyklus), diese in ein Software Projekt sinnvoll eingegliedert werden können. Seite 8 von 17

9 3.1 Eclipse Projekte werden in Maven nicht im Eclipse erstellt, sondern mit einem Maven Befehl ins Leben gerufen. Apache stellt ein Plugin zur Verfügung, welches abhängig vom Project Object Model die Eclipse Projektdateien generiert. Wird dieses Plugin in den Lebenszyklus integriert, kann mit Eclipse ohne zusätzlichen Aufwand gearbeitet werden. Einmalig muss die M2_REPO Variable im Eclipse definiert werden, die zum local Repository zeigt. Window Preferences Java Build Path Classpath Variable New Das Eclipse Projekt soll in diesem Beispiel in der Phase validate erstellt werden, so dass gleich mit Beginn des Lebenszyklus mit Eclipse gearbeitet werden kann. Folgende Tags sind dafür in der pom.xml nötig: <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-eclipse-plugin</artifactid> <executions> <execution> <phase>validate</phase> <goals> <goal>eclipse</goal> </goals> </execution> </executions> </plugin> Welches Plugin? Bei welcher Lebensphase? 3.2 Site Das Site Plugin, das ebenfalls Apache zur Verfügung stellt, generiert eine Dokumentation des Projektes im html Format. Dabei werden Informationen aus dem pom.xml File gewonnen, um die Internet-Site mit Inhalt zu füllen. Immer wenn ein Projekt in ein Format (z. B. jar) gepackt wird, also bei der Phase package, soll eine Projektsite erstellt werden. Seite 9 von 17

10 Analog zur pom-konfiguration beim Eclipse Plugin, muss auch hier das pom ergänzt werden: <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-site-plugin</artifactid> <executions> <execution> <phase>package</phase> <goals> <goal>site</goal> </goals> </execution> </executions> </plugin> Das Site Plugin verwendet Informationen aus der pom-konfiguration. Unter Anderen fliesst folgender Tag der Projektdefinition, der die Lizenzbedingungen definiert, in die Dokumentation mit ein. <licenses> <license> <name>freeware</name> <url>license.txt</url> <distribution></distribution> <comments>all rights reserved</comments> </license> </licenses> 3.3 JDepend Maven bietet die Möglichkeit Plugins selbst zu schreiben und diese in den Build Prozess einzubinden. Nachdem ein Plugin erstellt wurde, kann es wie in den vorherigen Kapiteln gesehen in den Lebenszyklus eines Projektes eingebunden werden. Dieses Plugin startet eine JDepend Auswertung. Dieser Test kann so fix in Form des Plugins in den Lebenszyklus integriert werden. Seite 10 von 17

11 Plugin Implementation: Ein Plugin muss von der Klasse AbstractMojo erben. Die execute-methode, die dabei implementiert werden muss, dient als Startpunkt des Plugins. package com.mycompany.app; import org.apache.maven.plugin.abstractmojo; import org.apache.maven.plugin.mojoexecutionexception; /** jdepend start JDepend test */ public class JDepend extends AbstractMojo { public void execute() throws MojoExecutionException { String[] args = {"C:\\eigeneDateien\\ \\mvn_radio"}; jdepend.textui.jdepend.main(args); } } Das Plugin ruft die main-methode der JDepend Klasse auf und simuliert so das Starten des JDepend-Testvorganges von der Kommandozeile. Eine Abhängigkeit (siehe Kapitel 4) ist auch bei Plugins nötig, damit der Zugang zu den Klassen AbstractMojo und MojoExecutionException gewährleistet ist: <project > <modelversion>4.0.0</modelversion> <groupid>com.mycompany.app</groupid> <artifactid>mvn_plugin</artifactid> <packaging>maven-plugin</packaging> <version>1.0</version> <name>testevaluation with JDepend</name> <dependencies> <dependency> <groupid>org.apache.maven</groupid> <artifactid>maven-plugin-api</artifactid> <version>2.0</version> </dependency> </dependencies> </project> Seite 11 von 17

12 Einbindung in Lebenszyklus eines Projektes Nachdem ein Plugin mit mvn install/ mvn deploy im Repository verfügbar gemacht wurde, kann es vom Projekt wie von bereitgestellten Plugins gewohnt, in den Lebenszyklus integriert werden. <plugin> <groupid>com.mycompany.app</groupid> <artifactid>mvn_plugin</artifactid> <executions> <execution> <phase>generate-test-resources</phase> <goals> <goal>jdepend</goal> </goals> </execution> </executions> </plugin> </plugins> Der JDepend Test wird bei der generate-test-resource Lebensphase ausgeführt. 4 Transitve Abhängigkeiten Die Abhängigkeiten eines Programms von anderen Programmen (Libraries) werden im pom.xml File definiert. Mit diesen Abhängigkeiten wird die Verwendung von Bibliotheken strukturierter und automatisiert. Beim Kompilieren, Testen oder Ausführen eines Programmes werden Abhängigkeiten mit in den Build-Prozess miteinbezogen (auch die Abhängigkeiten der Abhängigkeit Abhängigkeiten werden an Submodule vererbt). Damit Programme von einem Paket abhängen können, muss dieses mit mvn install/ mvn deploy in einem lokalen/ remote Repository zur Verfügung gestellt werden. Die pom.xml Datei muss um einen dependency Tag ergänzt werden, um solch eine Abhängigkeit zu definieren. <dependency> <groupid>hibernate</groupid> <artifactid>hibernate</artifactid> <version>3.0.3</version> <scope>compile</scope> </dependency> Der Scope definiert, für was die Abhängigkeit gilt. Folgende Scopes werden angeboten: Compile: Provided: Runtime: Test: Abhängigkeit in allen Phasen (default) Abhängigkeit nur beim Kompilieren, nicht beim Ausführen Abhängigkeit nur beim Ausführen, nicht beim Kompilieren Abhängigkeit zum Kompilieren und Ausführen von Tests (JUNIT) Seite 12 von 17

13 Falls das Submodul und das Vatermodul nicht die gleiche Version einer Library verlangen, verwendet Maven die Regel nearest wins. In zukünftigen Versionen soll dieses Schema austauschbar sein. 5 Plugins vs. Abhängigkeiten Plugins sind Java Programme. Dieses Kapitel soll den Unterschied zwischen Abhängigkeiten und Plugins herausheben. Während Plugins vom Lebenszyklus eines Projektes aufgerufen werden können und so in den Buildprozess eines Projektes eingreiffen, sind Abhängigkeiten normale Programme, die das Mutterprogramm benötigt. Meist handelt es sich dabei um Bibliotheken, welche zur Laufzeit verwendet werden. 6 Variablen zur Laufzeit Maven bietet die Möglichkeit Informationen aus der pom.xml Datei in die JAR Datei zu packen (über application.properties / test.properties Textfiles). Dazu muss die Dateistruktur erweitert my-app -- pom.xml `-- src -- main -- java `-- com `-- mycompany `-- app `-- App.java `-- resources `-- META-INF `-- application.properties `-- test -- java `-- com `-- mycompany `-- app `-- AppTest.java `-- resources `-- test.properties neu neu und die pom.xml Datei mit folgenden Zeilen ergänzt werden. <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> </build> Seite 13 von 17

14 Folgendes lässt sich mit dieser Konfiguration durch einen mvn package Befehl beobachten: In src- Verzeichnis # application.properties application.name=${pom.name} application.version=${pom.version} In der Jar Datei # application.properties application.name=maven Quick Start Archetype application.version=1.0-snapshot Auf diese Werte kann zur Laufzeit des Programms zugegriffen werden (z.b. Versionsnummer):... // Retrieve resource InputStream is; is = getclass().getresourceasstream( "/application.properties" ); // Do something with the resource Seite 14 von 17

15 Dokumentation Bibliographie Artikel aus Fachzeitschriften Kundlacz, Heiko Maven 2: Build-Tool mit neuer Architektur. In: ix, 2/2006. S Internetseiten Ferguson, John. An introduction to Maven 2. (05. Dez. 2005) Apache Maven Project. Introduction to the Build Lifecycle. (Feb. 2006) Abbildungsverzeichnis Abbildung Abbildung 1 Abbildung 2 Quellenangabe Eigene Kreation maven.html Anhang Komplettes POM <project xmlns=" xmlns:xsi=" xsi:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>com.mycompany.app</groupid> <artifactid>mvn_radio</artifactid> <packaging>jar</packaging> <version>1.0</version> <name>radio Maven Example</name> <url> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> Seite 15 von 17

16 <licenses> <license> <name>freeware</name> <url>license.txt</url> <distribution></distribution> <comments>all rights reserved</comments> </license> </licenses> <build> <plugins> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-eclipse-plugin</artifactid> <executions> <execution> <phase>validate</phase> <goals> <goal>eclipse</goal> </goals> </execution> </executions> </plugin> <plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-site-plugin</artifactid> <executions> <execution> <phase>package</phase> <goals> <goal>site</goal> </goals> </execution> </executions> </plugin> <plugin> <groupid>com.mycompany.app</groupid> <artifactid>mvn_plugin</artifactid> <executions> <execution> <phase>generate-test-resources</phase> <goals> <goal>jdepend</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project> Seite 16 von 17

17 Ehrlichkeitserklärung Hiermit erkläre ich, die vorliegende Arbeit selbständig und ohne Beizug unerlaubter Hilfsmittel verfasst zu haben. Windisch, 21. Feb Jonas Weibel Seite 17 von 17