2.  Konfiguration und Funktionsweise

2.1.  Inbetriebnahme

Maven ist auf zahlreichen Plattformen einsetzbar. An dieser Stelle soll lediglich auf die Installation auf Unix basierten, sowie Windows Systemen eingegangen werden. Alle Systeme setzten für den Betrieb voraus, dass mindestens das Java Development Kit 1.4 installiert ist. Die aktuelle Version von Maven steht auf der offiziellen Projekt Homepage zum Download bereit. Nach der Installation kann durch Eingabe von mvn --version in der Kommandozeile die Korrektheit der Installation überprüft werden.

2.1.1.  Installation unter Linux, Solaris und Mac OS X

1. Entpacken des Archivs in das gewünschte Verzeichnis (Beipiel: /usr/local/maven). Ein Unterverzeichnis mit der jeweiligen Version wird vom Archiv erstellt.
2. Hinzufügen der Umgebungsvariablen M2_HOME in einem Terminal Fenster.

   Beispiel: export M2_HOME=/usr/local/maven/apache-maven-2.0.9

3. Hinzufügen der Umgebungsvariablen M2. Beispiel: export M2=$M2_HOME/bin
4. Hinzufügen der Umgebungsvariablen für die Java Virtual Maschine:

   export MAVEN_OPTS="-Xms256m -Xmx512m"

5. Hinzufügen der Umgebungsvariabeln M2 zur Path-Variablen

2.1.2.  Installation Windows 2000/XP

1. Entpacken des Archivs in das gewünschte Verzeichnis (Beipiel: C:\programme\maven). Ein Unterverzeichnis mit der jeweiligen Version wird vom Archiv erstellt.
2. Hinzufügen der Umgebungsvariablen M2_HOME.

   (Rechtsclick Arbeitplatz -> Eigenschaften -> Erweitert -> Umgebungsvariablen)

   Beispiel: M2_HOME=C:\programme\maven\apache-maven-2.0.9

3. Hinzufügen der Umgebungsvariablen M2. Beispiel: M2=%M2_HOME%\bin
4. Hinzufügen der Umgebungsvariablen für die Java Virtual Maschine:

   MAVEN_OPTS="-Xms256m -Xmx512m"

5. Erweitern der Umgebungsvariabeln %M2% zur Path-Variablen

2.1.3.  Das Help-Plugin

Da Maven fast nur aus Plugins besteht, soll hier als erstes das Help-Plugin vorgestellt werden, da es mit ihm möglich ist, Informationen über ein Projekt und Hilfe zu anderen Plugins abzufragen. Der Aufruf eines Plugins erfolgt durch die Eingabe von mvn <plugin>:<goal>, wobei es sich bei <plugin> um den Pluginnamen handelt und bei <goal> um das Ziel, das mit dem Plugin erreicht werden soll. Die Ziele eines Plugins werden auf MOJOs genannt. Plugins haben unterschiedliche Ziele. Im Folgenden werden die wichtigsten Ziele für das Help-Plugin beschrieben:

• mvn help:active-profiles

  Dieser Aufruf gibt alle für das derzeitige Projekt gültigen Profile zurück. Da sich der Aufruf auf ein bestimmtes Projekt bezieht muss dieser Aufruf im Projekt-Stammordner erfolgen.

• mvn help:effective-pom

  Dieser Aufruf zeigt das komplette POM des Projekts an und muss ebenfalls im Projektstammordner aufgerufen werden.

• mvn help:effevtive-settings

  Dieser Aufruf zeigt alle Einstellugen an, die für das Projekt gelten und muss ebenfalls im Projektstammordner aufgerufen werden.

• mvn help:describe

  Hierbei handelt es sich um einen allgemeinen Aufruf mit dem die Hilfe eines Plugins angezeigt werden kann. Mit dem zusätzlichen Parameter -Ddetail wird eine ausführlichere Hilfe dargestellt. Beispiel: mvn help:describe -Dplugin=help

2.2.  ”Settings.xml”

Nach dem ersten Aufruf eines Maven Kommandos legt Maven im Benutzerverzeichnis des jeweiligen Betriebssystems ein lokales Repository an. In diesem Repository werden alle Abhängigkeiten gespeichert, die schon einmal von einem zentralen Repository bezogen wurden. Dies erklärt unter anderem auch die geringe Größe ( 1.5MiB), die Maven nach der Installation hat, denn Maven lädt alle zum jeweiligen Aufruf benötigten Plugins und andere Abhängigkeiten von einem zentralen Repository, wenn sie noch nicht im lokalen Repository lagen. Um Maven auf einem lokalen System an die gegebene Arbeitsumgebung anzupassen, sollte die Datei settings.xml im Benutzerverzeichnis verwendet werden. Diese muss unter Umständen neu angelegt werden. Weiterhin ist es möglich, in der Konfigurationsdatei verschiedene Benutzerprofile anzulegen, die andere Projektumgebungskonfigurationen beschreiben. Dies kann von grossem Nutzen sein, wenn auf unterschiedlichen Testsystemen gearbeitet wird oder verschiedene Datenbankserver verwendet werden sollen. Die jeweils aktiven Profile können ebenfalls in der Konfigurationsdatei ausgewählt werden.

Windows: \Dokumente und Einstellungen\user\.m2\

Linux: ~/.m2/

Sie dient zum Einrichten von:

• Proxyeinstellungen
• Serverlokationen und Credentials
• Mirror für Mavenrepositories

Weiterhin gibt es auch eine systemglobale Konfigurationsdatei settings.xml. Diese liegt im Unterverzeichnis .\conf\ des Installationsverzeichnisses von Maven. Wie oben bereits erwähnt, sollten die benutzerspezifischen Konfigurationsdateien verwendet werden, da es sonst zu Migrationsproblemen bei einem Update von Maven kommen könnte. In diesem Fall muss die bestehende globale Konfiguration über die neue globale Konfiguration geschrieben werden.

2.3.  Das Project Object Model

Das Project Object Model enthält alle Informationen über das dazugehörige Projekt. Dazu gehören:

• Coordinaten die das Projekt eindeutig identifizieren. Folgende Koordinaten müssen in jedem POM deklariert werden:
  • groupId : Gruppenzugehörigkeit
  • artifaktId : Artefaktname, Name des Projektes
  • version : Version des Projekts
  • packaging : Ergebnistyp des Projekts
• beschreibende Elemente
  • name : Projekttitel
  • url : Projekthomepage
  • developer : Entwickler des Projekts
• Einstellungen
  • Buildeinstellungen
  • Quellverzeichnisse
• Abhängigkeiten, die das Projekt benötigt
• Plugins, die für des Projekt benötigt werden. z.B.: Bug-Tracking-System, VersionControlSystem

Durch diese Angaben wird jedes Projekt für Maven beschrieben. Soll die Anwendung compiliert oder getestet werden, verarbeitet Maven das Projekt anhand des jeweiligen Projektkonfigurationsfiles. Jedes Projekt hat nur ein POM-File und aus jedem POM-File geht nur ein Artefakt (Assemblat) hervor. Die Projektstruktur ist vorgegeben. Die Konfigurationsdatei liegt immer <root>-Verzeichnis der Anwendung.

Beispiel: Einfaches POM.xml File

2.4.  Erstellen eines Projekts

Es gibt mehrere Möglichkeiten, um ein Projekt in Maven zu integrieren.

1. Erstellen eines neuen Projektes

   Maven verfügt über Projektschablonen. Diese Schablonen (Archetypes) sind Standartrichtlinien, die den Aufbau bestimmter Projekttypen beschreiben. Wird keine bestimmte Schablone beim Erstellen eines Projektes angegeben, wird als Default ein Java-Projekt mit einem JAR-File als Ergebnistyp erstellt. Es wäre auch denkbar ein Webprojekt anzulegen, welches dann allerdings in einem WAR-File resultieren würde.

   mvn archetype:create -DgroupId=org.fhwedel.mavenseminar.examples   -DartifactId=simple   -DpackageName=org.fhwedel.mavenseminar

   Dieser Aufruf erstellt ein neues JAR-Projekt mit dem Archetype maven-archetype-quickstart, indem das Ziel ”Create” des Plugins ”Archetype” aufgerufen wird. Mit Hilfe dieses Plugins wird eine neue Projektverzeichnisstruktur im Unterordner ./simple angelegt. Ebenso wird auch das POM für das Projekt angelegt. Von Projekttyp zu Projekttyp kann die Verzeichnisstruktur mit weiteren Verzeichnissen ergänzt werden. Bei einem WAR würde beispielsweise auch ein WEB-INF-Ordner mit angelegt werden. Die grundlegende Struktur ist jedoch weitestgehend gleich. (Thema: Konvention vor Konfiguration) Die Verzeichnisstruktur kann jedoch zu jeder Zeit im POM angepasst werden. Es ist auch möglich, eine eingabegesteuerte Projekterstellung durchzuführen. Dieses wird durch den Aufruf von mvn archetype:generate erreicht. Dort ist es dann möglich, eine der vielen Archetypes auszuwählen.

   Um das Projekt zu bauen und zu kompilieren wird im Projektstammverzeichnis mvn install aufgerufen. Dadurch wird das einfache ”Hello World” Projekt, das gerade durch das Archetype Plugin erstellt wurde gebaut und compiliert. Das Assemblat liegt dann im Target-Ordner und kann mit dem Exec-Plugin aufgerufen werden: mvn exec:java -Dexec.mainClass=org.fhwedel.examples.App

   [INFO] Scanning for projects...   [INFO] Searching repository for plugin with prefix: ’exec’.   [INFO] -----------------------------------------------------   [INFO] Building simple   [INFO]    task-segment: [exec:java]   [INFO] -----------------------------------------------------   [INFO] Preparing exec:java   [INFO] No goals needed for project - skipping   [INFO] [exec:java]   Hello World!   [INFO] -----------------------------------------------------   [INFO] BUILD SUCCESSFUL   [INFO] -----------------------------------------------------   [INFO] Total time: 1 second   [INFO] Finished at: Tue Dec 23 11:49:23 CET 2008   [INFO] Final Memory: 2M/4M   [INFO] -----------------------------------------------------

   Im folgenden Bild ist die Verzeichnisstruktur, die durch das Archetype-Plugin vorgegeben und angelegt wurde, abgebildet.

   

   • 1 Dieses Verzeichnis, mit dem Namen der ArtifactId, ist das Projektstammverzeichnis.
   • 2 Im Verzeichnis src befinden sich alle dem Projekt zugehörigen Klassen und Ressourcen.
   • 3 Im Main-Verzeichnis befinden sich der Quellcode und die Projektressourcen
   • 4 Im Test-Verzeichnis befinden sich zum Beispiel JUnit-Tests für das Projekt und die Ressourcen für die Testklassen
   • 5 Im target-Verzeichnis befinden sich nach dem Aufruf von mvn install das Assemblat des Projekts und die Dokumentationen und Reports
2. Migrieren eines bestehenden Projektes
   Daher ist es auch denkbar, für ein bereits bestehendes Projekt ein gültiges POM zu deklarieren, um so dieses Projekt in Maven zu migrieren. Dabei ist zu beachten, dass eventuell die Pfadangaben für die Source- und Target-Verzeichnisse angepasst werden müssen. Ebenso müssen die Koordinaten des Projekts eindeutig sein. Es darf jedes Artefakt nur einmal vorhanden sein. Denn wenn ein Artefakt installiert oder deployed wird, kann dieses nur ins lokale Repository übernommen werden wenn es eindeutig ist.

2.5.  Modularisierung

POMs können Module enthalten. Dazu werden in einem Parent POM die Untermodule angegeben. Die Verzeichnisse der Untermodule müssen in dem des Parent POMs liegen. Die Buildreihenfolge der Untermodule und deren Abhängigkeiten werden von Maven erkannt.

Die Einbindung von Untermodulen in einem POM:

Die Einbindung des Parent POMs in einem Untermodul

Das Parent POM vererbt dabei seine Buildeinstellungen und Konfigurationen an die Untermodule, die das Parent POM erwähnen.

2.6.  Die Lifecycle-Phasen

Jedes Projekt, beschrieben durch ein POM, verfügt über einen Lebenszyklus(Lifecycle) der in verschiedene Phasen aufgeteilt ist. Dabei verfügt jede Phase über verschiedene Ziele(Goals), die während einer Lifecycle Phase erreicht werden können. Alle Projekttypen verfügen über nahezu äquivalente Lebenszyklen, die bei umfassenderen Projekten lediglich erweitert werden. Um die Phasen auch für verschiedene Projekttypen abbilden zu können, greift jede Phase auf die dem Projekttyp entsprechenden Plugins zurück. Jedes Plugin ist dabei ein Ziel in der Lifecyclephase. Das folgende Bild zeigt die Abhängigkeit der Phasen von den Plugins eines einfachen JAR-Projekts.

Soll jetzt eine Lifecyclephase durch eingeben von mvn <Lifecyclephase> erreicht werden, so werden alle Lifecyclephasen durchlaufen, die für die aufgerufene Lifecyclephase benötigt werden.

Beispiele:

• mvn compile Um das Projekt zu compilieren werden zunächst durch die Lifecyclephase ”generate-sources” die Sourcen und Ressourcen für das Compilieren zur Verfügung gestellt. Dabei werden auch die abhängigen Bibliotheken oder anderen Artefakte, die benötigt werden, organisiert. Dann erst kann das Projekt compiliert werden.
• mvn test Um ein Projekt zu testen werden folgende Lifecyclephasen benötigt:
  • mvn generate-sources:Generiert alle Sourcen und Test-Sourcen
  • mvn compile:Compiliert das Projekt
  • mvn test-compile:Compiliert die Test-Klassen des Projekts

Die einzelnen Ziele eines Plugins können auch direkt aufgerufen werden. Dabei ist zu berücksichtigen, dass in diesem Fall nur dieses Ziel ausgeführt wird und nicht, wie bei den Lifecyclephasen alle benötigten vorhergehenden Ziele. Der Aufruf eines Ziels(Goal) eines Plugins erfolgt durch Eingabe von mvn plugin:goal.

Beispiele für Goal-Aufrufe:

• mvn help:effective-pom
• mvn help:effective-settings
• mvn compiler:compile
• mvn jar:jar
• mvn help:describe -Dplugin=compiler

Phasen und Goals können auch kombiniert werden:

• mvn clean compile jar:jar Durch diesen Aufruf werden zunächst alle Dateien aus dem Target-Verzeichnis des Projekts gelöscht. Durch die Lifecyclephase compile werden die Sourcen compiliert. Durch das Goal jar:jar wird das compilierte Package in den Target-Ordner kopiert und zur Verfügung gestellt.