Praktikum Softwarearchitektur. Apache Maven. Klaus-Christian Saalfeld. 18. Juni FernUniversität in Hagen

Transkript

1 Praktikum Softwarearchitektur Apache Maven 18. Juni 2011 FernUniversität in Hagen

2 Inhaltsverzeichnis 1. Einführung in Maven 1 2. Grundlagen Erste Schritte mit Maven Struktur und Beschreibung eines Projektes Build Lifecycles Repositories und Dependency Management Plugins Exemplarische Anwendung Ein ANT Projekt als Fallbeispiel Vergleich zwischen ANT und Maven Portierung des ANT Projektes Erzeugung eines neuen Maven Projektes Hinzufügen der Java Quellen Portierung der Unit-Tests Hinzufügen der C Quellen Erzeugung eines.jar Archivs Architektur Plugin-Architektur Maven als Plugin-Framework Entwicklung eines Plugins Integration in den Maven Build Dependency Injection Plexus als Dependency Injection Framework Zusammenfassung und Ausblick Zusammenfassung Ausblick A. Anhang 27 A.1. build.xml A.2. Makefile A.3. JniCompilerPluginMojo.java A.4. pom.xml Literaturverzeichnis 36 i

3 1. Einführung in Maven Maven (deutsch: Experte) ist ein Build Management System für Java Projekte. Es kombiniert Funktionalität zum Programmbau mit zusätzlichen Aspekten zum Management von Abhängigkeiten. Maven wird von der Apache Software Foundation als Open Source Software entwickelt und unter der Apache Software License lizensiert. 2. Grundlagen 2.1. Erste Schritte mit Maven Maven kann von der Webseite der Apache Software Foundation heruntergeladen werden. Die jeweils aktuelle Version findet sich auf: Für alle Beispiele in dieser Ausarbeitung wird Version benutzt. Für die Nutzung von Maven ist die Binär-Distribution (apache-maven bin.zip) ausreichend. Zur Installation von Maven wird das heruntergeladene Archiv in ein beliebiges Verzeichnis entpackt. Damit Maven auf der Shell verfügbar ist, muss anschließend das Unterverzeichnis bin zum Suchpfad des Systems hinzugefügt werden. Dazu ist die Umgebungsvariable PATH entsprechend zu modifizieren. Da Maven selbst auf Java basiert muss ein Java SDK installiert sein. Ein reines Java Runtime (JRE) ist nicht ausreichend. Für die Beispiele in dieser Ausarbeitung wird das Java SDK Version 6 Update 25 verwendet. Dieses kann von der Webseite von Oracle bezogen werden: Für gängige Betriebssysteme werden Installer angeboten. Die Installation kann in ein beliebiges Verzeichnis erfolgen. Nach der Installation muss jedoch ggf. die Umgebungsvariable JAVA_HOME angepaßt werden. Diese muss auf das Verzeichnis der Java SDK Installation zeigen. Die korrekte Installation von Maven kann auf der Shell mit folgender Eingabe geprüft werden: mvn --help Bei einer erfolgreichen Installation führt dies zu der (gekürzten) Ausgabe: usage: mvn [options] [<goal(s)>] [<phase(s)>] Options: -am,--also-make... If project list is specified, also build projects required by the list 1

4 Über das Kommando mvn können Maven Projekte gebaut und verwaltet werden. Alle, für die praktische Nutzung von Maven notwendigen, Operationen lassen sich darüber ausführen. Eine typische Operation wäre beispielsweise das Compilieren aller.java Quellen eines Projektes und das anschließende Packen in einem.jar Archiv. Mit Maven wird das, für ein Projekt im aktuellen Verzeichnis, wie folgt erreicht: mvn package Maven benötigt Zugang zum Internet. Sofern ein Proxy verwendet wird, ist es notwendig die Konfiguration von Maven entsprechend anzupassen. Dies geschieht über einen Eintrag in der Datei settings.xml: <settings> <proxies> <proxy> <active>true</active> <protocol>http</protocol> <host>proxy.company.de</host> <port>8080</port> <username>myusername</username> <password>mypassword</password> </proxy> Diese befindet sich im Verzeichnis: ~/.m2/ Vergleiche [Tim O Brien et al., 2010, A.2.4, Proxies, Seite 248] Struktur und Beschreibung eines Projektes Vergleiche [Vincent Massol et al., 2008, Seite 28], [Tim O Brien et al., 2008, Kapitel 3.4, Seite 34f] und [Tim O Brien et al., 2010, Kapitel 3, The Project Object Model, Seite 17ff]. Ein Maven Projekt wird über das Project Object Model (kurz: POM) beschrieben. Die Beschreibung erfolgt für jedes Projekt im XML Format in der Datei pom.xml. Diese kann als Analogie zu build.xml (ANT) oder zum Makefile (Make) verstanden werden. Als Unterschied enthält sie aber, wie in Kapitel 3.2 noch beschrieben wird, keine Beschreibung der Build-Schritte, sondern eine rein deklarative Beschreibung des Projektes. Ein minimales Beispiel 1 einer pom.xml Datei kann wie folgt aussehen: 1 Vergleiche [Tim O Brien et al., 2010, Kapitel 3.2.2, The Simplest POM, Seite 22] 2

5 <project> <modelversion>4.0.0</modelversion> <groupid>com.company.project</groupid> <artifactid>samplejavaproject</artifactid> <version>1.0</version> </project> Als erste Information enthält sie die Coordinate des Projektes in Form der Tags groupid, artifactid und version. Die Coordinate dient als eindeutiger Bezeichner für das Projekt 2. Projekte müssen in Maven eindeutig identifizierbar sein, damit das Dependency Management und die Verwaltung der Maven Repositories funktioniert (siehe Kapitel 2.4). Die zweite Information in der gezeigten pom.xml Datei ist die Object Model Version, die durch den Tag modelversion gegeben ist [Vincent Massol et al., 2008, Seite 29]. Diese wählt indirekt die Super POM des Projektes. In Maven gibt es für POMs das Prinzip der Vererbung. Jedes POM erbt implizit die Informationen aus dieser Super POM. Dies funktioniert analog zur Vererbung in der objektorientierten Programmierung (OOP). Während jedoch in der OOP Felder und Methoden vererbt werden, werden in Maven POM Informationen in Gestalt von XML Daten weitervererbt. Durch die Vererbung wird das Konzept Convention Over Configuration von Maven unterstützt. Dieses wird in [Vincent Massol et al., 2008, Kapitel 1.2.1] beschrieben. Für Maven bedeutet es, dass für alle Einstellungen sinnvolle Standardwerte vorgegeben sind, die erst bei Notwendigkeit geändert werden müssen. Solche Einstellungen werden zum Teil durch Vererbung aus der Super POM, in die POM des jeweiligen Projektes, implizit übertragen. Neben dieser impliziten Vererbung aus der Super POM, können auch eigene POMs erstellt werden, von denen explizit geerbt werden kann. Ein Beispiel dazu findet sich in [Vincent Massol et al., 2008, Kapitel 3.3]. Das gezeigte Beispiel kann, obwohl es nur das Nötigste enthält, bereits genutzt werden, um ein Java Projekt mit Maven zu bauen. Dem Prinzip Convention Over Configuration folgend, ist die Struktur des Projektes dabei durch die Super POM vorgegeben. Die Java Quellen müssen, für einen erfolgreichen Bau, in das Unterverzeichnis src/main/java 3 kopiert werden. Für gewöhnlich ist es nicht notwendig und sinnvoll von dieser Vorgabe abzuweichen. Wie folgendes Beispiel zeigt, könnte es bei Bedarf aber getan werden: <project> <modelversion>4.0.0</modelversion> <groupid>com.company.project</groupid> <artifactid>samplejavaproject</artifactid> <version>1.0</version> 2 Der Sinn des Wortes Coordinate kann, wie in [Tim O Brien et al., 2008, Seite 45] dargestellt, verstanden werden: Analog zu einem Punkt in einem Koordinatensystem, kann jedes Projekt im Maven Space durch eine Coordinate eindeutig identifiziert werden. 3 Die aus dem Package resultierenden Verzeichnisstrukturen müssen hinzugefügt werden. 3

6 <build> <sourcedirectory>source/java</sourcedirectory> </build> </project> Das Beispiel überschreibt die Vorgaben aus der Super POM und legt source/java als neues Verzeichnis für Java Quellen fest. Das überschriebene Element wäre andernfalls durch die Super POM wie folgt definiert worden: <project> <build> <sourcedirectory>src/main/java</sourcedirectory> 2.3. Build Lifecycles Vergleiche [Tim O Brien et al., 2010, Kapitel 4, Seite 47ff], [Vincent Massol et al., 2008, Seite 30] und [Tim O Brien et al., 2008, Kapitel 3.5.2, Seite 38ff]. Ein wichtiges Konzept in Maven entspringt der Beobachtung, dass der Bau eines Projektes in immer gleichen Schritten mit einer wohldefinierten Reihenfolge erfolgt: Es müssen beispielsweise erst alle Quellen compiliert werden, bevor diese mit einem Unit-Test getestet werden können. Erst nachdem der Unit-Test erfolgreich war, kann das Projekt veröffentlicht oder anderen Nutzern zur Verfügung gestellt werden. Diese Aneinanderreihung von Schritten mit einer fest definierten Reihenfolge wird in Maven als Lifecycle bezeichnet 4. Maven ist nicht auf einen einzigen Lifecycle beschränkt - es integriert standardmäßig die Lifecycles default, clean und site. Die in einem Lifecycle abgearbeiteten Schritte werden Phasen genannt. Die Compilierung der Java Quellen findet beispielsweise im Lifecycle default in der Phase compile statt 5. Bei der praktischen Arbeit mit Maven wird üblicherweise die auszuführende Phase vorgegeben. Es werden dann auch alle Phasen ausgeführt, die im Lifecycle vor dieser Phase verankert sind. Um zum Beispiel die Phase compile und alle vorangehenden Phasen auszuführen, kann folgendes Kommando verwendet werden: mvn compile Die dabei ausgeführte Funktionalität ist nicht fest mit der Phase verbunden. Man kann sich vereinfacht vorstellen, dass Phasen völlig ohne Funktion sind und lediglich als Anknüpfungspunkte für Funktionalität dienen. Funktionalität wird in Form sog. Goals an die Phasen 4 Das Wort Cycle (deutsch: Zyklus) kann in diesem Zusammenhang zunächst verwirren, da der Bau eher als Sequenz anzusehen ist, die an einem bestimmten Punkt erfolgreich abgeschlossen und damit beendet ist. Ein Zyklus entsteht erst über die Lebenszeit des Projektes gesehen, da in dieser Zeit mit jedem Bau die Sequenz immer wieder von Neuem durchlaufen wird. 5 Eine vollständige Liste der Phasen ist in [Tim O Brien et al., 2010, Kapitel 4.1.2, Seite 50f] angegeben. Die Phasen des clean und site Lifecycles sind in [Tim O Brien et al., 2010, Kapitel 4.1.1, Seite 48ff] beschrieben. 4

7 gebunden. Die Goals werden dabei über Plugins zur Verfügung gestellt. Mehr dazu siehe Kapitel 2.5 und 4.1. Es ist auch möglich, einzelne Goals explizit auszuführen. Dazu wird das Plugin, wie in folgendem Schema gezeigt, mit seiner groupid, artifactid und version vorgegeben und das auszuführende Goal benannt: mvn groupid:artifactid:version:goal Vergleiche dazu [Tim O Brien et al., 2010, Kapitel , A Simple Java Mojo, Seite 186]. Um für ein Projekt Unit Tests auszuführen, ohne dabei den Lifecycle zu durchlaufen, kann beispielsweise folgender Aufruf verwendet werden: mvn org.apache.maven.plugins:maven-surefire-plugin:2.7.2:test 2.4. Repositories und Dependency Management Softwareprojekte nutzen häufig externe Bibliotheken und Frameworks. Da diese zum Bau des Softwareprojektes notwendig sind, werden sie auch Dependencies genannt. Für Java Projekte stehen diese Dependencies meist als.jar Packages zur Verfügung. Dependencies können in unterschiedlichen Versionen vorliegen und ihrerseits weitere Dependencies besitzen (sog. Transitive Dependencies [Tim O Brien et al., 2010, Kapitel 3.4.4, Transitive Dependencies, Seite 31]). Deshalb kann es in der Praxis schwierig sein, für ein Softwareprojekt ein korrektes Setup aller Dependencies zu erzeugen. Maven entlastet den Entwickler von dieser Arbeit, indem es das Dependency Management übernimmt. In der Praxis funktioniert das Dependency Management, indem in der Datei pom.xml die benötigten Dependencies des Projektes definiert werden. Download und Verwaltung dieser Dependencies (und ggf. weiterer transitiver Dependencies) übernimmt Maven. Maven lädt benötigte Dependencies automatisch aus einem Remote Repository herunter 6. Das voreingestellte Remote Repository ist: Die Dependencies werden in einem lokalen Repository abgelegt. Bei zukünftigen Builds werden die Dependencies aus dem lokalen Repository verwendet, sodaß sie nicht erneut aus dem Remote Depository bezogen werden müssen. Das lokale Repository befindet sich per Default im Home Verzeichnis des Benutzers unter: ~/.m2/repository Ein Beispiel für eine Dependency ist JUnit. Ein Projekt, das JUnit für seine Unit Tests benötigt, kann diese Dependency in der Datei pom.xml angeben: 6 Dazu ist eine Internetverbindung erforderlich. Gerade nach einer Erstinstallation wird Maven beim Bau eines Projektes eine große Anzahl an Dependencies aus dem Remote Repository herunterladen. 5

8 <project> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> Die Dependency muss dazu, wie in Kapitel 2.2 beschrieben, durch ihre Coordinate eindeutig identifiziert werden. Sofern JUnit noch nicht im lokalen Repository verfügbar ist, wird die gewünschte Version, vor dem Ausführen der Tests, zunächst aus dem Remote Repository übertragen. Bei der Ausführung der Tests wird der classpath durch Maven dann geeignet ergänzt:...:~/.m2/repository/junit/junit/3.8.1/junit jar Vertiefende Informationen zum Dependency Management mit Maven finden sich in [Tim O Brien et al., 2010, Kapitel 3.4, Project Dependencies, Seite 27] Plugins Vergleiche [Tim O Brien et al., 2010, Kapitel , What is a Plugin?]: Ein großer Teil der Funktionalität von Maven wird durch Plugins bereitgestellt. Eine Liste bereits verfügbarer Plugins findet sich unter: Plugins für Maven werden in Java geschrieben und typischerweise mit Maven selbst gebaut 7. Äußerlich unterscheidet sich ein Plugin nicht von einem normalen Maven Projekt: Fertig gebaut liegt es als.jar Package vor, das in ein Repository installiert und so von anderen Maven Nutzern verwendet werden kann. Zusätzlich zu den compilierten Klassen, enthält das Package lediglich einen Plugin Descriptor, der zusätzliche Informationen für die Nutzung des Plugins durch Maven liefert. Ein Plugin stellt ein oder mehrere Goals zur Verfügung. Ein solches Goal kann, wie in Kapitel 2.3 beschrieben, an eine Phase im Lifecycle gebunden werden. Wie in Kapitel 4.1 noch gezeigt wird, kann man sich ein Goal auch als Java Methode vorstellen, die von Maven aufgerufen wird. Jedes Goal wird in einer eigenen Klasse implementiert. Da ein Plugin mehrere Goals zur Verfügung stellen kann, kann es mehrere solcher Klassen enthalten. Eine Klasse, die ein Goal implementiert, wird auch Mojo genannt. Ein Mojo stellt somit genau ein Goal zur Verfügung. 7 Maven besitzt für diesen Zweck ein eigenes Plugin namens maven-plugin-plugin 6

9 3. Exemplarische Anwendung 3.1. Ein ANT Projekt als Fallbeispiel Um den praktischen Umgang mit Maven zu zeigen, soll exemplarisch ein ANT Projekt für Maven portiert werden. Ein gibt Literatur in welcher der Einstieg in Maven anhand eines Beispiel-Projektes beschrieben ist. Insbesondere [Vincent Massol et al., 2008, Kapitel 3, Seite 55ff] soll an dieser Stelle genannt werden. Ein Problem der Arbeiten zu diesem Thema ist jedoch, dass verständlicherweise Beispiele gewählt werden, die optimal für Maven geeignet sind. In der Praxis ist es jedoch häufig die eigentliche Herausforderung, die Grenzen einer Technologie zu kennen, um entscheiden zu können, ob sie für die Lösung eines Problems sinnvoll ist oder nicht. Eine derartige Abgrenzung wird in der Literatur selten vorgenommen, da primär die Vorteile einer neuen Technologie herausgestellt werden. In dieser Arbeit wurde deshalb ein reales Beispiel gewählt, das an den Randbereichen des sinnvollen Einsatzgebietes von Maven vermutet wird. Das exemplarisch gewählte Projekt ergänzt Java über JNI mit Funktionalität zum Lesen und Verändern der Microsoft Windows Registry. Es hat zwei Bestandteile: Ein in Java erstellter Teil und eine in C geschriebene DLL. Das Projekt wird bisher mit ANT gebaut. Zwar wird die DLL mit Make erzeugt (siehe Anhang A.2), die entsprechenden Aufrufe werden allerdings vom ANT Skript (siehe Anhang A.1) delegiert. Insgesamt wird der Bau des Projektes also über ANT gesteuert Vergleich zwischen ANT und Maven Ein wichtiger Aspekt von Maven ist der Programmbau. Da Maven aber auch weitere Funktionalitäten beinhaltet, ist es kein reines Tool zum Programmbau wie ANT (oder das klassische Make). Für einen Vergleich wird hier deshalb zunächst nur der Aspekt des Programmbaus betrachtet. Um die Unterschiede zu reinen Build-Tools zu verdeutlichen, wird auch kurz das klassische Make betrachtet. Beim Programmbau unterscheidet sich Maven von ANT und Make: In ANT und Make werden Ziele und Abhängigkeiten spezifiziert. Für jedes Ziel werden dann die notwendigen Aktionen beschrieben um es zu erreichen. Als eine grobe Unterscheidung zwischen ANT und Make kann festgestellt werden, dass in ANT die Aktionen (hier Tasks genannt) abstrakter sind als in Make. Dies kann an einem kleinen Beispiel verdeutlicht werden. Ein Ziel beim Bau eines Java Projektes besteht beispielsweise in der Erzeugung von.class Dateien aus den.java Quelldateien, welche in diesem Fall die Abhängigkeiten darstellen. Eine Lösungsmöglichkeit in Make wäre die folgende:.phony: all compile 7

10 all:.depend compile.depend: echo "compile: \\" >.depend find. -name "*.java" -type f \ sed -n "s%^\(.*\)\.java.*%\1.class \\\\\\%p" >>.depend -include.depend %.class: %.java javac $< Das Äquivalent in ANT ist im Folgenden dargestellt: <project name="samplejavaproject" default="compile"> <target name="compile"> <javac srcdir="." includeantruntime="false" /> </target> </project> Beide Lösungen haben offensichtliche Unterschiede 8. Als Gemeinsamkeit kann für beide aber festgestellt werden, dass die notwendigen Schritte für einen erfolgreichen Bau des Projektes beschrieben werden. Im Gegensatz dazu, wird in Maven das zu bauende Projekt beschrieben. Der Weg, wie ein Projekt zu bauen ist, muss nicht angegeben werden. Es gibt demnach auch keine Ziele und Abhängigkeiten. Die notwendigen Schritte für den erfolgreichen Bau werden von Maven für das Projekt passend gewählt und ausgeführt. Ein korrespondierendes Maven Projekt 9 (genauer: die Datei pom.xml) sähe wie folgt aus: <project> <modelversion>4.0.0</modelversion> <groupid>com.company.project</groupid> <artifactid>samplejavaproject</artifactid> <version>1.0</version> </project> Man sieht, dass hier weder einzelne Build-Schritte noch die, dem Projekt zugeordneten, Quelldateien definiert sind. Damit dies funktionieren kann, muss man sich allerdings an die Konventionen von Maven halten (siehe Kapitel 2.2). 8 Das Beispiel zeigt, dass ANT in Bezug auf die Verständlichkeit Vorteile bringt. Auch Plattformunabhängigkeit ist ein weiterer wichtiger Vorteil von ANT - das Makefile dieses Beispiels funktioniert nur auf unixoiden Systemen. Flexibilität ist hingegen der große Vorteil von Make - beispielsweise steuert es die Übersetzung der L A TEX Quellen dieser Arbeit. 9 Vergleiche [Tim O Brien et al., 2010, Kapitel 3.2.2, Seite 22] 8

11 3.3. Portierung des ANT Projektes Erzeugung eines neuen Maven Projektes Erster Schritt bei der Portierung ist die Erzeugung eines neuen Maven Projektes. Dies geschieht wie folgt: mvn archetype:create -DgroupId=com.sse.jregedit \ -DartifactId=JRegEdit -Dversion=1.0 Maven erzeugt dadurch ein neues Projekt, das einen minimalen Satz an Beispiel-Dateien enthält. Hierbei von Interesse ist lediglich die Datei pom.xml und die erzeugten Verzeichnisse - die restlichen.java Dateien sind Beispiele und können gelöscht werden. Es ist nicht zwingend ein neues Projekt auf diese Weise zu erzeugen. Es wäre ebenso möglich gewesen, die notwendigen Dateien und Verzeichnisse von Hand zu erstellen. Die Datei- und Verzeichnisstruktur sollte am Ende lediglich wie folgt aussehen: JRegEdit / pom.xml / src / main / java / com / sse / jregedit / test / java / com / sse / jregedit Der Inhalt der erzeugten pom.xml sieht wie folgt aus: <project xmlns=" xmlns:xsi=" xsi:schemalocation=" \ <modelversion>4.0.0</modelversion> <groupid>com.sse.jregedit</groupid> <artifactid>jregedit</artifactid> <version>1.0</version> <packaging>jar</packaging> <name>jregedit</name> <url> <properties> <project.build.sourceencoding>utf-8</project.build.sourceencoding> </properties> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> 9

12 </dependency> </dependencies> </project> Hinzufügen der Java Quellen Als zweiter Schritt werden die Java Quellen dem neuen Maven Projekt hinzugefügt. Die Java Quellen (ohne die Unit-Test Klassen) werden in die Verzeichnisstruktur unterhalb von src eingefügt. Dies resultiert in folgender Projektstruktur 10 : JRegEdit / pom.xml / src / main / java / [...] / JRegEdit.java / JRegEditException.java / JRegEditKeyChangeListener.java / JRegEditListenHandle.java / JRegEditListenProperties.java / test / java / [...] / Die Quellen können nun mit Maven wie folgt compiliert werden: mvn compile Die compilierten.class Dateien werden in einer neuen Verzeichnisstruktur gespeichert: JRegEdit / target / classes / [...] / JRegEdit.class / JRegEditException.class / JRegEditKeyChangeListener.class / JRegEditListenHandle.class / JRegEditListenProperties.class Das Löschen der erzeugten Dateien geschieht mit Maven wie folgt: mvn clean Portierung der Unit-Tests Ein nächster Schritt bei der Portierung ist das Hinzufügen der Klassen für die Unit-Tests. Maven unterstützt Unit-Tests mit JUnit als Standard 11. Es macht Sinn, sich dieser Konvention anzupassen und den proprietären Unit-Test für JUnit zu portieren. Dies ermöglicht es jedem Entwickler (ganz im Sinne von Maven) sich schnell in das Projekt einzuarbeiten, da vorhandenes Wissen aus anderen Maven Projekten (wie z.b. über JUnit) wiederverwendet werden kann. Die Einarbeitung in (unnötige) Eigenheiten des Projektes wie ein proprietärer 10 Die aus dem Package Namen com.sse.jregedit resultierenden Verzeichnisse (com/sse/jregedit) werden zur besseren Übersichtlichkeit hier und in den folgenden Ausführungen durch [...] ersetzt. 11 In Maven wird diese Funktionalität über das Surefire Plugin maven-surefire-plugin realisiert. 10

13 Unit-Test entfällt in diesem Fall. Der portierte Unit-Test wird in Form der Klasse JRegEditTest.java in das Projekt eingebunden. Die Unit-Test Quellen werden nicht unterhalb von src, sondern unterhalb des Verzeichnisses test eingefügt: JRegEdit / test / java / [...] / JRegEditTest.java Um die Tests auszuführen wird folgendes Kommando verwendet: mvn test Auf das Beispiel angewendet, führt das Kommando zur folgenden Ausgabe (gekürzt und aufbereitet): T E S T S Running com.sse.jregedit.jregedittest Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: sec <<< FAILURE! Results : Tests in error: testregcreatekey(com.sse.jregedit.jregedittest): no jregedit in java.library.path testregdeletekey(com.sse.jregedit.jregedittest): Could not initialize class com.sse.jregedit.jregedit testregexistskey(com.sse.jregedit.jregedittest): Could not initialize class com.sse.jregedit.jregedit... Tests run: 18, Failures: 0, Errors: 18, Skipped: 0 [INFO] [INFO] BUILD FAILURE [INFO] Wie hier zu sehen ist, treten beim Test Fehler auf. Der Grund für diese Fehler liegt in der fehlenden DLL die noch nicht dem neuen Maven Projekt hinzugefügt wurde. Wird diese testweise in das aktuelle Verzeichnis kopiert 12, werden die Unit-Tests bestanden: Es genügt diese in ein Verzeichnis zu legen, welches das System nach DLLs durchsucht. 11

14 T E S T S Running com.sse.jregedit.jregedittest Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: sec Results : Tests run: 18, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESS [INFO] Sofern die DLL noch nicht erzeugt vorliegt, kann die Phase test auch explizit übersprungen werden. Dies zeigt folgendes Beispiel, das ein Package aus den compilierten Klassen erzeugt, ohne diese zuvor zu testen: mvn package -Dmaven.test.skip=true Als Reaktion auf mvn test werden die Java Quellen des Unit-Tests und (soforn notwendig) alle Java Quellen des Projektes compiliert 13. Die compilierten Unit-Test Klassen werden in einem neuen Verzeichnis der Projektstruktur abgelegt: JRegEdit / target / test-classes / [...] / JRegEditTest.class / JRegEditTest$1.class / JRegEditTest$2.class / JRegEditTest$3.class Mit der Ausführung der Unit-Tests werden weitere Verzeichnisse erzeugt. In diesen werden unter anderem die Ergebnisse der Tests gespeichert Hinzufügen der C Quellen Nachdem der Bau der Java Quellen funktioniert, ist ein nächster Schritt, die Erzeugung der DLL in den Build-Prozess zu integrieren. Zunächst werden dazu die C Quellen dem Projekt hinzugefügt. Da Maven keine Vorgabe besitzt, wo diese abzulegen sind, muss das Verzeichnis selbst gewählt werden. Die C Quellen werden wie folgt in die Projektstruktur eingefügt 14 : JRegEdit / src / main / native / windows / app / jni / reg / utils / win32 13 Dies resultiert aus der Tatsache, dass die Phase test im Default Lifecycle nach der Phase compile und test-compile verankert ist 14 Die Namen der.c und.cpp Dateien werden, der Übersichtlichkeit wegen, nicht dargestellt 12

15 Wie sich mit dem Kommando mvn compile prüfen läßt, hatte das Hinzufügen der Dateien noch keinen Einfluss auf den Build. Das Ziel wäre das gleiche Verhalten zu erhalten wie bei Verwendung des ANT Skriptes (siehe Anhang A.1): Ein Bauen der Java Quellen über das Target all führt hier auch zum Compilieren der C Quellen. Alle Bauprodukte werden gemeinsam durch das Target clean wieder entfernt. Um ein solches Verhalten mit Maven zu erzielen, müssen neue Goals an die Phasen im Lifecycle gebunden werden (siehe Kapitel 2.3). Dies wird durch Modifikation der Datei pom.xml erreicht. Das Verfahren dazu wird beispielhaft in [Vincent Massol et al., 2008, Kapitel 3.7, Seite 68f] beschrieben und liegt auch der hier vorgestellten Lösung zu Grunde. Um das gleiche Verhalten wie bei Verwendung des ANT Skriptes zu erhalten, kann ein zusätzliches Goal an die Phase compile im Default Lifecycle gebunden werden, das die Compilierung der C Quellen übernimmt. Ein an clean gebundenes Goal, kann die, aus den C Quellen erzeugten, Bauprodukte wieder entfernen. Die einfachste Lösung dafür scheint hier die Verwendung des Plugins exec-maven-plugin zu sein, welches das Goal exec bereitstellt. Dieses erlaubt die Ausführung beliebiger Anwendungen 15. Dadurch ist es möglich, die genannten Aufgaben wie bisher an Make zu delegieren. Es wird dazu der folgende Ausschnitt unterhalb von project! build! plugins in die Datei pom.xml eingefügt: <plugin> <groupid>org.codehaus.mojo</groupid> <artifactid>exec-maven-plugin</artifactid> <version>1.2</version> <executions> <execution> <id>native-compile</id> <phase>compile</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>make</executable> <commandlineargs>-c./src/main/native/windows all</commandlineargs> </configuration> </execution> <execution> <id>native-clean</id> <phase>clean</phase> <goals> <goal>exec</goal> </goals> <configuration> 15 Vergleiche 13

16 <executable>make</executable> <commandlineargs>-c./src/main/native/windows clean</commandlineargs> </configuration> </execution> </executions> </plugin> Das Kommando mvn compile führt nun zur Ausgabe (gekürzt und aufbereitet):... [INFO] --- maven-compiler-plugin:2.3.2:compile JRegEdit --- [INFO] Compiling 5 source files to D:\JRegEdit\target\classes [INFO] [INFO] --- exec-maven-plugin:1.2:exec JRegEdit --- make.exe: Entering directory D:/JRegEdit/src/main/native/windows... g++ -s -shared -static-libgcc -static -mwindows -o jregedit.dll utils/utils.o win32/win32_utils.o app/reg_key_copy.o app/reg_key_create.o app/reg_key_delete.o app/reg_key_enum.o app/reg_key_exists.o app/reg_key_flush.o app/reg_key_listen.o app/reg_key_map.o app/reg_value_create.o app/reg_value_delete.o app/reg_value_enum.o app/reg_value_exists.o app/reg_value_get.o jni/jni_exception.o jni/jni_object.o reg/reg_utils.o jregedit.o jregedit.res jregedit.def -O3 -Wall -Wextra make.exe: Leaving directory D:/JRegEdit/src/main/native/windows [INFO] [INFO] BUILD SUCCESS [INFO] Ein anschließendes mvn clean führt zur Ausgabe (gekürzt und aufbereitet):... [INFO] --- maven-clean-plugin:2.4.1:clean JRegEdit --- [INFO] Deleting D:\JRegEdit\target [INFO] [INFO] --- exec-maven-plugin:1.2:exec JRegEdit --- make.exe: Entering directory D:/JRegEdit/src/main/native/windows... rm -f utils/utils.o win32/win32_utils.o app/reg_key_copy.o app/reg_key_create.o app/reg_key_delete.o app/reg_key_enum.o app/reg_key_exists.o app/reg_key_flush.o app/reg_key_listen.o app/reg_key_map.o app/reg_value_create.o app/reg_value_delete.o app/reg_value_enum.o app/reg_value_exists.o app/reg_value_get.o jni/jni_exception.o jni/jni_object.o reg/reg_utils.o jregedit.o make.exe: Leaving directory D:/JRegEdit/src/main/native/windows 14

17 [INFO] [INFO] BUILD SUCCESS [INFO] Bei einem Blick in das ANT Skript (siehe Anhang A.1) fällt auf, dass die Erzeugung der JNI Header Datei mit Hilfe von javah und die Kopieraktionen noch nicht in pom.xml integriert wurden. Dies wäre ebenfalls nach der hier vorgestellten Methode möglich. Man kann aber darüber streiten, ob die hier vorgestellte Lösung dem Grundgedanken von Maven entspricht, da mit dem exec-maven-plugin eigentlich wieder Build-Schritte beschrieben werden - nur wesentlich umständlicher. Ein JNI Plugin welches den Bau der DLL aus C Quellen übernimmt wäre eine sauberere Lösung. In Kapitel 4.1 wird ein solcher Ansatz vorgestellt Erzeugung eines.jar Archivs Die bei der Compilierung erzeugten.class Dateien werden über mvn package in einem.jar Archiv gepackt. Als zusätzliche Aufgabe muss diesem die DLL hinzugefügt werden. Alle Versuche, dies direkt durch Konfiguration von maven-jar-plugin zu erreichen, blieben ohne Erfolg 16. In diesem Fall könnte mit Assemblies gearbeitet werden. Mit Assemblies können benutzerdefinierte Zusammenstellungen von Dateien als Package erzeugt werden. Dies funktionierte im Versuch gut, führte allerdings zu weiterer Arbeit, da das erzeugte Package nicht automatisch mit in das Repository installiert wird. Der Versuch wurde an diesem Punkt deshalb beendet. Zur Lösung dieses Problems wird in Kapitel 4.1 ein Plugin entwickelt und beschrieben. 4. Architektur 4.1. Plugin-Architektur Maven als Plugin-Framework Ein großer Teil der Funktionalität wird in Maven durch Plugins bereitgestellt. Man kann Maven deshalb auch als Plugin-Framework ansehen. Um diese Architektur zu verstehen, soll exemplarisch ein neues Plugin für Maven erstellt werden. An diesem Beispiel wird gezeigt, wie und mit welchen Techniken das Plugin in Maven integriert wird. 16 Das Einbinden von Dateien funktioniert offenbar nur unterhalb des classesdirectory. Dieses kann zwar umkonfiguriert werden, dadurch ändern sich allerdings auch die Pfade im.jar Archiv. 15

18 Entwicklung eines Plugins Das exemplarisch entwickelte Plugin (siehe Anhang A.3) knüpft an den Erkenntnissen aus Kapitel an. Dort wurde die Portierung eines ANT basierten JNI Projektes beschrieben. Es wurde gezeigt, wie ein bestehendes Makefile, das den Bau der C Quellen übernimmt, in den Maven Build integriert werden kann. Allein mit den verfügbaren Bordmitteln waren aber nicht alle Probleme in akzeptabler Zeit lösbar. Auch wurde angemerkt, dass die vorgestellte Lösung im Sinne von Maven nicht optimal ist. An dieser Stelle wird deshalb zur Lösung der Probleme ein JNI Plugin entwickelt, dass den Bau des nativen Teils des JNI Projektes übernimmt. Ein neues Plugin wird über den bereits bekannten Archetype Mechanismus wie folgt erzeugt: mvn archetype:create -DgroupId=com.sse.maven.jni \ -DartifactId=maven-jni-compiler-plugin \ -DarchetypeArtifactId=maven-archetype-mojo Die entwickelte Plugin-Klasse JniCompilerPluginMojo.java (siehe Anhang A.3) kann anschließend in die erzeugte Verzeichnisstruktur \maven-jni-compiler-plugin\src\main\java\com\sse\maven\jni eingefügt werden. Alle Beispiel-Klassen können aus dem Projekt entfernt werden. Das Plugin kann anschließend mit mvn compile compiliert werden. Die Bestandteile eines Maven Plugins werden exemplarisch anhand der entwickelten Plugin- Klasse JniCompilerPluginMojo.java vorgestellt. Diese kann auf folgendes Grundgerüst reduziert werden: package com.sse.maven.jni; import org.apache.maven.plugin.abstractmojo; import org.apache.maven.plugin.mojoexecutionexception; /** compile compile */ public class JniCompilerPluginMojo extends AbstractMojo public void execute() throws MojoExecutionException //... 16

19 Für jedes Goal enthält ein Plugin eine Klasse, die direkt oder indirekt das Interface org.apache.maven.plugin.mojo implementiert. Hier geschieht das durch Ableitung von AbstractMojo. Die von einem Goal bereitgestellte Funktionalität muss über die Methode execute() implementiert werden. Diese Methode wird von Maven aufgerufen, um ein Goal auszuführen. Nicht immer kann ein Goal erfolgreich abgeschlossen werden: Beispielsweise kann ein Syntaxfehler den erfolgreichen Bau der Java Quellen mit dem maven-compiler-plugin verhindern. In solchen Fällen kann die Methode eine MojoExecutionException werfen. Der Maven Build wird dann mit einem Fehler abgebrochen: [ERROR] Failed to execute goal org.apache.maven.plugins: maven-compiler-plugin:2.3.2:compile (default-compile) on project... Die Klasse AbstractMojo stellt auch ein Log bereit, mit dem eigene Ausgaben erzeugt werden können. Vergleiche [Tim O Brien et al., 2010, Kapitel , Mojo Class Annotations]: Bei der Klasse fallen Annotationen auf, die nicht mit Javadoc in Zusammenhang stehen. Aus diesen wird automatisch beim Bau des Plugins der Plugin Descriptor erzeugt, welcher als XML Datei in das.jar Package eingebunden wird. Über die wird der Name des Goals festgelegt, welches die Klasse bereitstellt. Die ist optional und bezeichnet die Phase, an welche das Goal standardmäßig gebunden ist, falls der Nutzer des Plugins keine explizite Bindung vorgibt. Der Plugin Descriptor findet sich im Package des Plugins unter: /META-INF/maven/plugin.xml Über die Annotationen werden dem Plugin Descriptor folgende Informationen hinzugefügt: <plugin> <mojos> <mojo> <goal>compile</goal> <phase>compile</phase> </mojo> Durch die Verwendung von Annotationen muss der Plugin Descriptor nicht manuell erstellt oder angepaßt werden. Grundsätzlich wäre dies aber auch möglich. In vielen Fällen ist es notwendig, im Plugin auf Informationen über den Build zuzugreifen. Quelle dieser Informationen ist unter anderem die Datei pom.xml eines Projektes 17. Der Zugriff auf diese Daten wird ebenfalls durch Annotationen und damit über den Plugin Descriptor ermöglicht. Der folgende Ausschnitt zeigt beispielhaft den Zugriff auf die artifactid und groupid eines Projektes: 17 Genauer: Die aus Super POM und ggf. anderen POMs gebildete Effective POM. Diese kann man sich durch das Kommando mvn help:effective-pom anzeigen lassen. 17

20 public class JniCompilerPluginMojo extends AbstractMojo /** expression="$project.artifactid" */ private String artifactid; /** expression="$project.groupid" */ private String groupid; //... Wird das Goal in einem Projekt verwendet, stehen die artifactid und groupid des Projektes, dem instanziierten Objekt, in den hier gezeigten, gleichnamigen, privaten Feldern zur Verfügung. Im Plugin Descriptor wurden dazu folgende Einträge ergänzt: <plugin> <mojos> <mojo> <parameters> <parameter> <name>artifactid</name> <type>java.lang.string</type> <required>true</required> <editable>true</editable> <description /> </parameter> <parameter> <name>groupid</name> <type>java.lang.string</type> <required>true</required> <editable>true</editable> <description /> </parameter> In Kapitel 4.2 wird diese Umsetzung noch einmal genauer betrachtet Integration in den Maven Build Das vorgestellte Plugin kann mit folgendem Kommando compiliert und in das lokale Repository installiert werden: mvn install 18

21 Nachdem das Plugin im lokalen Repository abgelegt wurde, kann es im JNI Projekt verwendet werden. Dazu wird die pom.xml des JNI Projektes (siehe Anhang A.4) wie folgt ergänzt: <project> <build> <plugins> <plugin> <groupid>com.sse.maven.jni</groupid> <artifactid>maven-jni-compiler-plugin</artifactid> <version>1.0</version> <executions> <!-- this binds the JNI compiler plugin to the compile phase --> <execution> <phase>compile</phase> <goals> <goal>compile</goal> </goals> </execution> Dies bindet das vom Plugin bereitgestellte Goal compile an die compile Phase im Default Lifecycle. Es wird nun beim Compilieren des JNI Projektes automatisch in der Phase compile ausgeführt. Das Bauen des JNI Projektes mit mvn compile führt dann zu folgender Ausgabe (gekürzt und optisch aufgearbeitet):... [INFO] --- maven-jni-compiler-plugin:1.0:compile JRegEdit --- [INFO] javah -jni -classpath "D:\JRegEdit_Maven\target\classes" -o "D:\JRegEdit_Maven\target\native\windows\JRegEdit_jni.h" com.sse.jregedit.jregedit... [INFO] g++ -c "D:\JRegEdit_Maven\src\main\native\windows\app\reg_key_create.cpp" -o "D:\JRegEdit_Maven\target\native\windows\app\reg_key_create.o" -I"D:\JRegEdit_Maven\src\main\native\windows" -I"D:\Programme\Java\jdk1.6.0_24\include" -I"D:\Programme\Java\jdk1.6.0_24\include\win32" -I"D:\JRegEdit_Maven\target\native\windows" -O3 -Wall -Wextra... [INFO] windres -i "D:\JRegEdit_Maven\src\main\native\windows\jregedit.rc" --input-format=rc -o "D:\JRegEdit_Maven\target\native\windows\jregedit.res" -O coff... 19

22 [INFO] g++ -s -shared -static-libgcc -static -o "D:\JRegEdit_Maven\target\native\windows\JRegEdit.dll" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_copy.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_create.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_delete.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_enum.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_exists.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_flush.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_listen.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_key_map.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_value_create.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_value_delete.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_value_enum.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_value_exists.o" "D:\JRegEdit_Maven\target\native\windows\app\reg_value_get.o" "D:\JRegEdit_Maven\target\native\windows\jni\jni_exception.o" "D:\JRegEdit_Maven\target\native\windows\jni\jni_object.o" "D:\JRegEdit_Maven\target\native\windows\reg\reg_utils.o" "D:\JRegEdit_Maven\target\native\windows\jregedit.o" "D:\JRegEdit_Maven\target\native\windows\utils\utils.o" "D:\JRegEdit_Maven\target\native\windows\win32\win32_utils.o" "D:\JRegEdit_Maven\target\native\windows\jregedit.res" "D:\JRegEdit_Maven\src\main\native\windows\JRegEdit.def" -O3 -Wall -Wextra [INFO] [INFO] BUILD SUCCESS [INFO] Es verbleibt ein offener Punkt aus Kapitel 3.3.5: Das Hinzufügen der DLL in das.jar Archiv. Das entwickelte Plugin bietet dafür eine Lösung. Per Konfiguration des Parameters nativeoutputartifactplacements in der Datei pom.xml (siehe Anhang A.4) kann die erzeugte DLL an beliebige Orte im Projekt und im System kopiert werden: <plugin> <groupid>com.sse.maven.jni</groupid> <artifactid>maven-jni-compiler-plugin</artifactid> <configuration> <nativeoutputartifactplacements> <nativeoutputartifactplacement> $basedir </nativeoutputartifactplacement> <nativeoutputartifactplacement> $project.build.outputdirectory/com/sse/jregedit/resources </nativeoutputartifactplacement> </nativeoutputartifactplacements> </configuration> </plugin> 20

23 Die DLL wird darüber in die von maven-jar-plugin genutzten Verzeichnisse kopiert, sodaß sie automatisch in das Package eingebunden wird. Durch das Kopieren der DLL in ein Verzeichnis, aus dem das System Libraries lädt (hier: $basedir), kann auch das Problem des Testens gelöst werden (siehe Kapitel 3.3.3). Für den Test wird dadurch immer die aktuelle Version der DLL gefunden und genutzt. Ein Problem besitzt das Plugin dann allerdings doch: Der Bau der C Quellen erfolgt, im Vergleich zum originalen Projekt aus Kapitel 3, nicht mehr inkrementell. Eine solche Lösung wäre deutlich aufwändiger Dependency Injection In Kapitel 4.1 wurde ein Plugin für Maven entwickelt und vorgestellt. An diesem Beispiel war zu sehen, dass per XML in der Datei pom.xml definierte Inhalte über private Felder des Plugins verfügbar waren. Ein solches Beispiel ist das Feld nativeincludepaths: public class JniCompilerPluginMojo extends AbstractMojo /** */ private File[] nativeincludepaths; //... Der Inhalt dieses Feldes kann per XML festgelegt werden. Dies geschieht wie folgt: <project> <build> <plugins> <plugin> <configuration> <!-- puts two path names as File objects in nativeincludepaths --> <nativeincludepaths> <nativeincludepath> $env.java_home/include </nativeincludepath> <nativeincludepath> $env.java_home/include/win32 </nativeincludepath> </nativeincludepaths> Aus Sicht des umgebenden Objektes, ist das Feld, ohne weiteres Zutun, sofort korrekt initialisiert. Das Feld ist private und über keine öffentlichen Methoden nach außen verfügbar. 21

24 Es ist deshalb zunächst offensichtlich, dass es eines speziellen Sprachmittels (Reflection) bedarf, um das Feld wie gesehen zu initialisieren. Es stellt sich darüber hinaus allerdings die Frage, welchen Sinn ein solches Vorgehen hat. So wäre es durchaus auch denkbar, dass das Feld vom Objekt selbst initialisiert wird und der Initialwert beispielsweise aus einer externen Factory bezogen wird. Mit der Antwort auf diese Frage beschäftigt sich dieses Kapitel. Zunächst jedoch eine Definition: Das gezeigte Prinzip nennt sich Dependency Injection (DI) und die dahinter stehende allgemeine Idee Inversion of Control (IoC). Dependency Injection 18 bezeichnet also das Prinzip, dass ein Objekt benötigte Objekte nicht selbst erzeugt, sondern dass diese extern erzeugt und von außen eingefügt werden. Da dabei die Kontrolle über die Erzeugung aus dem Objekt selbst nach außen verlagert wird, spricht man hierbei von Inversion of Control. Frameworks, die dies umsetzen, werden auch Inversion of Control Container genannt. Mit Dependency Injection begegnet man Problemen, die sich insbesondere bei großen Softwaresystemen ergeben können: Betrachtet man eine objektorientiere Software zur Laufzeit, so stellt sich diese als ein Netz miteinander verbundener Objekte dar. Es stellt sich die Frage, wer die Dependencies für diese Objekte erzeugt. Als klassische Möglichkeit erzeugt jedes Objekt seine Dependencies selbst. Dies ist oft zu unflexibel. Man kann dann mit Factories arbeiten. Insbesondere beim Testen großer Systeme können hierbei aber auch die Grenzen erreicht sein. In solchen Fällen kann man auf Dependency Injection zurückgreifen, das hier Vorteile bringt: Zur Realisierung von Dependency Injection werden häufig Frameworks verwendet, bei welchen die Abhängigkeiten in XML Dateien abgelegt sind. Für Testzwecke können darüber Abhängigkeiten leicht und ohne Änderungen im Quellcode getauscht werden. Beispielsweise kann ein via TCP/IP kommunizierendes Objekt gegen ein Test-Objekt (Mock-Objekt) getauscht werden, das gezielt Fehlerfälle simuliert. Auch können beliebige Zusammenstellungen von Objekten leichter realisiert werden. 19 Dependency Injection kann auf verschiedene Arten umgesetzt werden. Diese unterscheiden sich darin, wie Abhängigkeiten in ein Objekt eingefügt werden. Unter anderem existieren dazu folgenden Möglichkeiten: Setter Injection Abhängigkeiten werden über eine öffentliche Setter Methode in ein Feld übernommen. 18 Zur Erklärung dieser Wortschöpfung: Ein Objekt das in einem Feld eine Referenz auf ein anderes Objekt besitzt, ist von dem referenzierten Objekt abhängig: Ohne das referenzierte andere Objekt könnte das Objekt selbst seine Arbeit typischerweise nicht verrichten. Man spricht deshalb in diesem Fall von einer Dependency (deutsch: Abhängigkeit). Wird diese nicht vom Objekt selbst erzeugt sondern von außen eingeschleußt, liegt eine Injection vor. 19 Dependency Injection bringt aber nicht nur Vorteile: Da die Identität von abhängigen Objekten im Quellcode nicht mehr erkennbar ist, kann das Verständnis der Zusammenhänge erschwert werden. Auch sind Kenntnisse über das Dependency Injection Framework notwendig. Probleme ergeben sich auch für Analyse-Tools, die auf statischer Ebene arbeiten sowie für bestimmte Funktionen in Entwicklungsumgebungen. 22

25 Constructor Injection Abhängigkeiten werden dem Konstruktor als Parameter bei der Objekt Instanziierung übergeben. Field Injection Abhängigkeiten werden über Reflection direkt in ein Feld geschrieben. Eine weiterführende Einführung in Dependency Injection findet sich in Fowler [2004]. Ein kurzer Vergleich verschiedener Dependency Injection Frameworks kann in Sanitz [2005] gefunden werden Plexus als Dependency Injection Framework In Kapitel 4.2 wird Dependency Injection und seine Verwendung in Maven vorgestellt. Maven nutzt ein Framework namens Plexus um Dependency Injection zu realisieren [Tim O Brien et al., 2010, Kapitel , What is Inversion of Control?]. Das Framework und weiterführende Informationen finden sich unter: Siehe auch [Tim O Brien et al., 2010, Kapitel , Why Plexus?]. Es kann an dieser Stelle keine komplette Einführung in Plexus erfolgen. Die Verwendung von Plexus soll aber beispielhaft am Maven Quellcode gezeigt werden. Es wird hier der gekürzte Ausschnitt aus DefaultMavenPluginManager.java gezeigt, der das Laden von Mojos über Plexus realisiert: package org.apache.maven.plugin.internal; public class DefaultMavenPluginManager // implements... private PlexusContainer container; public <T> T getconfiguredmojo( Class<T> mojointerface,..., MojoExecution mojoexecution ) // throws... MojoDescriptor mojodescriptor = mojoexecution.getmojodescriptor(); T mojo; mojo = container.lookup( mojointerface, mojodescriptor.getrolehint() ); populatepluginfields( mojo, mojodescriptor,... ); return mojo; 23

26 Innerhalb der Methode getconfiguredmojo() wird das Mojo über ein PlexusContainer Objekt mittels lookup() geladen. Die Methode populatepluginfields() übernimmt, mit der Hilfe von Plexus, anschließend die Dependency Injection der Mojo Felder. Die lookup() Methode ist in Plexus definiert als: package org.codehaus.plexus; public class DefaultPlexusContainer // extends... implements... public <T> T lookup( Class<T> type, String rolehint ) throws ComponentLookupException return componentregistry.lookup( type, type.getname(), rolehint ); Sie erhält zwei Parameter: Der Parameter type bezeichnet die Klasse oder das Interface des gewünschten Objektes. Mit rolehint wird das Objekt in einer Menge möglicher Kandidaten exakt bestimmt. Hier bestünde die Menge möglicher Kandidaten aus allen Mojo implementierenden Klassen. Über den Parameter rolehint kann dann, die für ein bestimmtes Goal benötigte Mojo Klasse genau bestimmt werden. Die Funktion getconfiguredmojo() liefert das fertig konstruierte Mojo an den Aufrufer zurück. Dies ist die Methode executemojo() in der Klasse DefaultBuildPluginManager.java. Hier wird schließlich die aus Kapitel bekannte execute() Methode des Mojos aufgerufen: package org.apache.maven.plugin; public class DefaultBuildPluginManager // implements... private MavenPluginManager mavenpluginmanager; public void executemojo( MavenSession session, MojoExecution mojoexecution ) // throws... Mojo mojo = null; mojo = mavenpluginmanager.getconfiguredmojo( Mojo.class, session, mojoexecution ); mojo.execute(); 24

27 5. Zusammenfassung und Ausblick 5.1. Zusammenfassung Kapitel 1 stellt Apache Maven als Open Source Build Management System für Java Projekte vor. Ein praktisch orientierter Einstieg in Maven beginnt in Kapitel 2 mit einer Kurzfassung wesentlicher Grundlagen. In Kapitel 3 wird ein exemplarisch gewähltes JNI Projekt von ANT nach Maven portiert. Es werden die Unterschiede zu ANT dargelegt und die Probleme bei der Portierung aufgezeigt. Um diese zu lösen, geht Kapitel 4 zunächst auf architektonische Aspekte von Maven ein und beschreibt es als Plugin-Framework. Zum erfolgreichen Bau des JNI Projektes wird, darauf aufbauend, ein neues Maven Plugin entwickelt. Zum Verständnis des Plugins, werden relevante Techniken (Dependency Injection) und benutzte Frameworks (Plexus) kurz vorgestellt Ausblick Write programs that do one thing and do it well. Wikipedia [2011] Maven vereint viel Funktionalität. Erfolgreiche Software erkennt man aber oft an einer scharfen funktionalen Begrenzung bei einem klar definierten Einsatzzweck. Ein exemplarisches Beispiel für diese Theorie soll die Mozilla Suite sein. Die Mozilla Suite kombiniert Browser, -Client, Adressbuch und einen HTML Composer. Ihre offizielle Weiterentwicklung wurde von der Mozilla Foundation jedoch zu Gunsten von Firefox eingestellt - einem reinen Browser. Auch Thunderbird, ein aus der Mozilla Suite isolierter -Client, hat respektablen Erfolg. Als Begründung für die offizielle Einstellung der Weiterentwicklung wird genannt: Der Hauptgrund für diese Änderung [die Konzentration auf die Weiterentwicklung von Firefox und Thunderbird] ist, dass die Akzeptanz von Einzelapplikationen bei den Anwendern als höher angenommen wurde als die einer kompletten Applikationssuite [...] 20 Die Mozilla Suite wird als unabhängiges Projekt namens SeaMonkey weiterentwickelt 21. Ein Blick auf eine aktuelle Browserstatistik 22 zeigt, dass SeaMonkey aber nur noch marginale Bedeutung hat. Rule of Composition: Design programs to be connected to other programs. Wikipedia [2011] Übertragen auf Maven wäre insbesondere zu fragen, ob Repository-Verwaltung, Dependency Management und Build Tool sich separiert nicht erfolgreicher weiterentwickeln können als der kombinierte Ansatz von Maven. Dazu wäre insbesondere die Annahme zu untersuchen, dass mit zunehmender Kopplung unterschiedlicher Funktionalitäten, die universelle Verwendbarkeit