Maven2 - Die nächste Generation des Buildmanagements?

Die nächste Generation des
Build-Managements?

Copyright 2006 Thorsten Kamann 1
itemis products & solutions GmbH & Co. KG

Inhalt

 Problematik Buildmanagement
 Verfügbare Build-Tools
 Shellskripte, Make-Files, Ant, Maven
 Unterschiede und Gemeinsamkeiten von Ant und Maven
 Die Konzepte von Maven
 Features von Maven
 Lebenszyklen, Projektdeskriptor, Transitive Abhängigkeiten, Repositories,
Plugins, Assemblies, Projektwebseite, Benutzereinstellungen
 Integration in Eclipse und Netbeans
 Erweiterungsmöglichkeiten von Maven
 Archetypen, Plugins (Java und Ant), Wagon-Provider
 Verwendung von Maven mit Ant
 Links

Problematik Buildmanagement

 Warum brauche ich ein Build(management)-Tool?

 Viele Aufgaben während des Entwicklungsprozesses bestehen aus vielen
einzelnen Schritten
 Die IDE kann nur für eine begrenzte Anzahl von Common-Tasks Support
bieten
 Für Continous Integration Systeme muss es möglich sein den Build-Vorgang
automatisch durchzuführen
 In einem Projekt wird häufig von Entwicklern mit unterschiedlichen IDE's
und Systemkonfigurationen entwickelt


Build-Tools

 Eine Auswahl bekannter Build-Tools
 Shell-, Batchskripte
 Make-Files
 Ant
 Maven


Build-Tools: Shell-, Batchskripte

 Vorteil:
 Systemnahes Skripting
 Ideal für Quick-Hacks
 Evtl. ausreichend für sehr kleine Teams auf einer bestimmten Plattform

 Nachteile:
 Keine Plattform-Neutralität, dh. für Linux und Win32-System müssen
unterschiedliche Skripte erzeugt werden
 Wartbarkeit ist sehr schlecht
 Ufert oft in Skriptorgien aus


Build-Tools: Make-Files

 Vorteile:
 Ideal für Projekte, die auf C basieren
 Support von den entsprechenden IDE's
 Viel Know-How im Internet verfügbar

 Nachteile:
 Sehr fehleranfällig
 Mit Projektgrösse leidet auch die Wartbarkeit
 Oftmals nicht Plattform-neutral
 Für Projekte anderer Programmiersprachen
nicht (oder nur schwerlich) zu verwenden


Build-Tools: Ant

 Vorteile:
 Sehr einfach verwendbar, da XML-Syntax verwendet wird
 Sehr guter Support von IDE's
 Auch für grosse Projekte noch wartbar
 Erweiterbar und auch für Aufgaben ausserhalb des Buildmanagements
benutzbar

 Nachteile:
 Kein standardisiertes Vorgehen, d.h. jedes Projekt erfindet
seinen Lifecycle neu
 Bietet keine vorgefertigten Tools, die das Erstellen
von immer wiederkehrenden Tasks überflüssig macht


Build-Tools: Maven

 Vorteile:
 Build-Prozess wird konfiguriert, nicht „programmiert“
 Leistungsfähiges Dependency-Management mittels Repositories
 Definierter Projekt-Lifecycle
 Sehr erweiterbar und anpassbar
 Schnell und resourcenschonend
 Deckt alle Facetten des Buildmanagement ab (z.B. Projektwebseite)

 Nachteile:
 Kein direkter Zugriff auf die einzelnen Tasks, wie z.B.
bei Ant
 Der Build-Prozess wird dadurch etwas abstrakter
 Nicht für alle Tasks gibt es bereits Maven-Plugins

Ant und Maven - Gemeinsamkeiten

 Top-Level Projekt bei der Apache Software Foundation (ASF)
 Java-basiert und garantiert so für eine hohe Modularität
 Basiert auf einem XML-Format
 Wird erfolgreich in vielen (OpenSource-)Projekten eingesetzt
 Grosse Community und viel Know-How im Internet/Printmedien
 Viele Drittanbieter bieten zusätzliche Komponenten und/oder Produkte


Ant und Maven – Unterschiede

 Ant  Maven
 Kein Dependency-Management  Transitives Dependency-
verfügbar Management ist zentraler
Bestandteil
 Jeder Teilaspekt des Build-  Viele Teilaspekte werden Out-Of-
Prozess muss jedes Mal neu The-Box mitgeliefert
erstellt werden (z.B. Javac, Unit)
 Kein ähnliches Konzept verfügbar  Sämtliche Projektinformationen
befinden sich an einer zentralen
Stelle (pom.xml)
 Kein ähnliches Konzept verfügbar  Sehr einfach komplett auf
Domänen anpassbar
 Geignet auch für Aufgaben  Ist darauf nicht ausgelegt
ausserhalb von SW-Projekten

Maven - Die Konzepte

 Jedes Projekt erzeugt ein Artefakt
 Artefakte bestehen aus einer Gruppen-ID (groupId), Artefakt-ID (artifactId)
( (
und einer Versionsnummer (version)
(
 Jedes Projekt hat nur einen Source- und einen Test-Baum
 Dies kann durch bestimmte Aktionen (generate-Goal) erweitert werden
(
 Der Buildprozess ist in Lebenszyklen (lifecycle, phase) aufgeteilt
(
 Jeder Lebenszyklus kann ein oder mehrere Ziele (goals) haben
(
 Es müssen nur die Dinge konfiguriert werden, die vom Standard abweichen
(SuperPOM)
 Abhängigkeiten sollen zentral verwaltet werden und von mehreren Projekten
verwendet werden können
 Die Komplexität heutiger Buildskripte soll verringert werden und einem
deskriptiven Format weichen

Maven – Die Features

 Einfaches und anpassbares Projektsetup
 Projektstrukturen sind konsistent, neue Entwickler brauchen nur wenig Zeit, um
sich einzuarbeiten
 Transitives Dependency-Management
 Bibliotheken können über verschiedene Projekte „geshared“ werden
 Remote und lokale Repositories für die Verteilung von Projektartefakten
 Die selben Metadaten werden für den Build-Prozess wie auch für zusätzliche
Informationen wie z.B. die Projektwebsite und Dokumentation genutzt
 Mit wenig Konfiguration können Quellcodeverwaltungen und Release-
Management integriert werden
 Flexible Plugin-Struktur
 Support für Domänen-spezifische Strukturen


Maven - Features: Lebenszyklen eines Projekts

 Lebenszyklen sind eines der zentralen Konzepte von Maven
 Die meist gebräuchlichsten Lebenszyklen eines Projekts sind:
 validate – validiert das Projekt, ob alle Resourcen verfügbar sind
 compile – Kompiliert den Quellcode
 test – Führt die Unit-Tests aus
 package – Erstellt das Projekt-Artefakt, z.B. ein JAR
 integration-test – Führt Tests in der Zielumgebung aus
 verify – Überprüft die erstellten Pakete und führt evtl. vorhandene QS-Tests
durch
 install – Installiert das erstellte Artefakt in das lokale Repository
 deploy – Installiert das erstellte Artefakt in ein entferntes (öffentliches)
Repository


Maven - Features: Lebenszyklen eines Projekts

 Lebenszyklen sind hierarchisch aufgebaut, dh. beim Ausführen eines
bestimmten Lebenszyklus werden alle vorherigen automatisch mit ausgeführt:

mvn install

führt also validate, compile, test, package, verify und install aus.
 Plugins können mittels Annotations oder Konfiguration für einen bestimmten
Lebenszyklus bereit gestellt werden (siehe auch „Erweiterung von Maven“)


Maven – Features: Der Projektdeskriptor

 Jedes Projekt hat mindestens 1 Projektdeskriptor „pom.xml“
 Enthält die Projekt-Metadaten, z.B.:
 Informationen des Artefakts, das dieses Projekt erzeugt
 Informationen über die Entwickler (Name, Kontakt, Rollen)
 SourceControl
 Mailinglisten
 Repositories
 Plugin-Konfigurationen
 Abhängigkeiten
 Lizenzinformationen
 Buildkonfiguration
 Wird für das Deployment des Projektartifakts in ein Repository genutzt



 Eine einfache pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>de.itemis.maven</groupId>
<artifactId>maven-demo</artifactId>
<version>1.0</version>
</project>

 Braucht das Projekt noch Abhängigkeiten reicht es diese mit in den
Projektdeskriptor einzubinden:
<dependencies>
<dependency>
<groupId>GROUPID</groupId>
<artifactId>ARTIFACTID</artifactId>
<version>VERSION</version>
</dependency>
</dependencies>


 Braucht das Projekt ein zusätzliches Plugin lässt sich das ebenfalls sehr leicht
einbinden:

<build>
<plugins>
<plugin>
<groupId>PLUGIN_GROUPID</groupId>
<artifactId>PLUGIN_ARTIFACTID</artifactId>
<version>PLUGIN_VERSION</version><
[<configuration/>]
<plugin>
</plugins>
</build>


Maven – Features: Transitive Abhängigkeiten

 Eines der Hauptfeatures sind die transitiven Abhängigkeiten, dh. jede
Abhängigkeit kann ihre eigenen Abhängigkeiten mitliefern. In dem Beispiel
würde der Projektdeskriptor nur eine Abhängigkeit auf „Library A“ definieren.
Alle anderen Bibliotheken würden automatisch aufgelöst und würden dem
Projekt zur Verfügung stehen.



 Dieses Feature kann nicht deaktiviert werden. Wenn man vermeiden will, dass
abhängige Bibliotheken aufgelöst werden, kann man dies mit dem <exclusions>-
Tag erreichen:

<dependency>
[...]
<exclusions>
<exclusion>
<groupId>EXCLUSION_GROUPID</groupId>
<artifactId>EXCLUSION_ARTIFACTID</artifactId>
</exclusion>
</exclusions>
</dependency>



 Da ein Projekt aus bestimmten Lebenszyklen besteht (compile, test,
packaging...) gibt es auch verschiedene Classpaths.
 Während der unterschiedlichen Lebenszyklen eines Projekts werden auch nur
unterschiedliche Abhängigkeiten gebraucht (z.B. jUnit nur während des Tests).
 Jeder Abhängigkeit kann deswegen ein Scope übergeben werden:

<dependency>
<groupId>GROUPID</groupId>
<artifactId>ARTIFACTID</artifactId>
<version>VERSION</version>
<scope>SCOPE</scope>
</dependency>

 Die Auflösung des Scopes übernimmt Maven eigenständig und ist mit den
Lebenszyklen fest verdrahtet.



 Der Scope kann die folgenden Werte haben:
 compile – (standard). Abhängigkeiten in diesem Scope werden immer
aufgelöst
 provided – Abhängigkeiten dieses Scopes sind nicht transitiv und werden
gewöhnlich von dem JRE oder einem Container bereitgestellt
 runtime – Abhängigkeiten mit diesem Scope werden nur zur Laufzeit
gebraucht, sind also nur während des Testing und der Laufzeit verfügbar
 test – Abhängigkeiten, die für das Testing verwendet werden. Ein
klassisches Beispiel dafür ist die Abhängigkeit zur junit.jar
 system – Ähnlich wie der „provided“ Scope. Abhängigkeiten mit diesem
Scope werden nicht im Repository gesucht, sondern müssen vom Entwickler
manuell dem Projekt hinzugefügt werden.



Lifecycle/Scope Compile Provided Runtime System Test
Compile    

Runtime    

Test    

Tabelle 1: Übersicht Lifecycle <==> Scope


Maven – Features: Repositories

 Repositories sind Aufbewahrungsorte für Projektartefakte
 Unterteilen sich in lokale und entfernte (remote) Repositories
 Das lokale Repository ist üblicherweise unter ${user.home}/.m2/repository
zu finden
 Bekannte Remote-Repositories sind:
 http://www.ibiblio.org/maven2/
 http://snapshots.maven.codehaus.org/maven2/
 Das Maven-Goal „install“ kopiert das Projekt-Artefakt in das lokale Repository,
wohingegen „deploy“ in das entfernte Repository kopiert.
 Das entfernte Repository muss schreibbar sein (FTP, SSH), während zum
Auflösen der Abhängigkeiten ein normaler HTTP-Zugriff reicht


Maven – Features: Repositories

 Ein Repository hat eine definierte Verzeichnisstruktur, damit das Auffinden von
Artefakten und bestimmten Versionen standardisiert ist
 Innerhalb der Repositories werden die verschiedenen Projektartefakte nach
diesem Konzept abgelegt:
GROUPID/ARTIFACTID/VERSION/ARTIFACT-VERSION.jar
GROUPID/ARTIFACTID/VERSION/ARTIFACT-VERSION.pom
Die Punkte in GROUPID wird durch file.separator ersetzt.
Aus
<dependency>
<groupId>de.itemis.maven</groupId>
<artifactId>maven-demo</artifactId>
<version>1.0.2</version>
</dependency>
wird
de/itemis/maven/maven-demo/1.0.2/maven-demo-1.0.2.jar
de/itemis/maven/maven-demo/1.0.2/maven-demo-1.0.2.pom


Maven – Features: Plugins

 Jegliche Funktionalität von Maven wird von Plugins gekapselt
 Plugins werden in der pom.xml aktiviert und konfiguriert:
<build>
<plugins>
<plugin>
<groupId>PLUGIN_GROUPID</groupId>
<artifactId>PLUGIN_ARTIFACTID</artifactId>
<version>PLUGIN_VERSION</version><
[<configuration/>]
<plugin>
</plugins>
</build>
 Plugins können aus herkömmlichem Java-Code oder aus Ant-Skripten bestehen
 Es gibt eine Vielzahl an Plugins auf den Webseiten von Maven und Codehaus
 Diese Plugins sind ähnlich gut dokumentiert wie die Ant-Tasks


Maven – Features: Assemblies

 Assemblies sind Konfigurationen, um Distributionen zu erstellen
 Distributionen werden in einer eigenen XML-Datei konfiguriert und über
mvn assembly:assembly aufgerufen:
<assembly>
<id>bin</id>
<formats>
<format>tar.gz</format>
<format>zip</format>
</formats>
<fileSets>
<fileSet>
<includes><include>README*</include></includes>
</fileSet>
<fileSet>
<directory>target</directory>
<outputDirectory></outputDirectory>
<includes><include>*.jar</include></includes>
</fileSet>
</fileSets>
</assembly>

Maven – Features: Projektwebseite

 Maven kann anhand der Metadaten in der pom.xml eine Projektwebseite
erstellen
 Diese Seite wird auf Basis von Cocoon/Forrest erstellt, 2 recht ausgereifte XML-
Frameworks
 Jeder Teil dieser Projektwebseite ist anpassbar
 Als Eingabeformat wird XML, APT (Almost Plain Text – ein Wiki-ähnliches
Format) und FML (für FAQ-Seiten) unterstützt
 Als Ausgabeformat unterstützt Maven aktuell nur xHTML. PDF ist aber geplant.
 Unterstützung für Internationalisierung der Webseite ist auch integriert
 Dadurch, dass die Metadaten der pom.xml genutzt werden, entfällt die Pflege
organisatorischer Daten (wechselnde Entwickler, Änderungen bei Mailinglisten,
usw.)



 Wenn nur die Metadaten der pom.xml verwendet werden enthält die generierte
Webseite folgende Menüpunkte:

 Report über die verwendeten Abhängigkeiten
 Mailinglisten
 Continous Integration
 Quellcodeverwaltung
 Bugtracking
 Projektteam
 Lizenz



 Auch das Deployment der generierten Webseite übernimmt Ant
 In der pom.xml muss konfiguriert werden wohin die Seite hin deployed werden
soll:

<distributionManagement>
<site>
<id>website</id>
<url>scp://myserver/home/htdocs</url>
</site>
</distributionManagement>

Der Zugang zu dem Server wird in der settings.xml konfiguriert
 Ein einfaches mvn site-deploy lädt die Seite dann auf den Server


Maven - Features: Benutzereinstellungen

 Maven kann sowohl globale Einstellungen als auch Benutzereinstellungen haben
 Die Syntax ist in beiden Fällen gleich
 Die Benutzereinstellungen befinden sich unter
${user.home}/.m2/settings.xml
 Die globalen Einstellungen sind unter ${m2.home}/conf/settings.xml zu
finden
 U.a. können in den Einstellungen folgende Dinge konfiguriert werden:
 Repositories (lokale und entfernte)
 Mirrors für entfernte Repositories
 Zugangsberechtigungen
 Proxyeinstellungen
 Profile
 PluginGroups

Maven – Integration in Eclipse

 Es gibt bereits ein Plugin für Eclipse
 Mit ihm ist es möglich einfach Abhängigkeiten zu suchen und dem Projekt
hinzuzufügen, wobei die eigentlichen Bibliotheken aus dem lokalen Repository
gelinkt und nicht ins Projekt kopiert werden
 Über „External Launcher“ können die verschiedenen Lifecycles/Goals gestartet
werden
 Der verwendete Maven-Embedder bietet nicht die Leistungsfähigkeit wie das
Maven-CLI
 Es ist problemlos möglich Maven-CLI als external Launcher zu konfigurieren und
evtl. ist das auch eine sinnvolle Alternative, um im Plugin implementiert zu
werden


Maven – Integration in Netbeans

 Auch für Netbeans gibt es ein Modul, welches Maven in die IDE integriert
 Es bietet ein ähnliches Leistungsspektrum wie das Plugin für Eclipse
 Da auch hier der Maven-Embedder verwendet wird, gibt es ähnliche
Einschränkungen wie bei Eclipse


Maven - Erweiterungen

 Maven kann an fast allen Stellen angepasst und erweitert werden
 Domänen-spezifische Strukturen und Prozesse können nachgebildet werden
 Initiale Projektstrukturen können durch eigene Archetypen bereit gestellt
werden
 Bestehende Ant-Targets für besondere Aufgaben können ohne weiteres mit dem
Ant-Plugin oder einem eigenem Ant-basierten Plugin übernommen werden
 Projekt-Artefakte können in besonders geschützte Repositories deployed
werden
 Für spezielle Protokolle oder höhere Sicherheit können spezielle Wagon-
Provider implementiert werden


Maven – Erweiterungen: Eigene Archetypen

 Archetypen sind einfache Maven-Plugins
 Mittels eines Deskriptors werden die Verzeichnisstrukturen und Dateien, die das
Projekt initial haben soll, festgelegt
 Dateien werden als Resource mitgegeben, wobei an der Stelle beliebige
Platzhalter verwendet werden können, die dann bei der Erstellung des Projekts
als Java-Properties mitgegeben werden können
 Eine pom.xml für das neue Projekt kann schon mit den nötigen Konfigurationen
mitgeliefert werden (Dependencies, Projekttyp, Repositories)
 Ein
mvn archetype:create -DarchetypeGroupId=...
-DarchetypeArtefactId=... -DarchetypeVersion=...
[-Dproperty=...]
reicht um das komplette Projekt zu erstellen


Maven – Erweiterungen: Plugins (Java)

 Plugins heissen bei Maven Mojo
 Die Implementierung ist ähnlich einer ANT-Task
 Das Mojo muss nur org.apache.maven.plugin.AbstractMojo erweitern und die
Methode execute() überschreiben
 Mit Annotations können für das Mojo u.a. der Lifecycle (@phase), das Goal
(
(@goal) und eine Beschreibung (@description) gesetzt werden
(
 Für Parameter des Plugins gibt es die Annotation @parameter
 Parameter können auf erforderlich (@required) und/oder schreibgeschützt
(
(@readonly) gesetzt werden
 Das fertige Plugin kann mittels
mvn install bzw. mvn deploy
in ein entsprechendes Repository installiert werden und kann dann direkt von
anderen Projekten verwendet werden



package sample.plugin;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;

/**
* @goal sayhi
* @description Says quot;Hiquot; to the user
/
public class GreetingMojo extends AbstractMojo {
/**
* @parameter
* @required
*/
private String greeting;

public void execute() throws MojoExecutionException {
getLog().info(greeting);
}
}


<plugin>
<groupId>sample.plugin</groupId>
<artifactId>maven-hello-plugin</artifactId>
<configuration>
<greeting>Welcome</greeting>
</configuration>
<executions>
<execution>
<phase>compile</phase>
<goals>
<goal>sayhi</goal>
</goals>
</execution>
</executions>
</plugin>


Maven – Erweiterungen: Plugins (Ant)

 Maven bietet die Möglichkeit Plugins auf Basis von Ant-Skripten zu entwickeln
 Dabei ist es nicht nötig Java zu programmieren
 Das ist eine ideale Möglichkeit bestehende Ant-Tasks zu übernehmen die gar
nicht oder nur mit sehr viel Aufwand nachimplementiert werden können
 Die Konfiguration und Parameterisierung der Ant-Targets werden in den Plugin-
Metadaten vorgenommen
 Es können sämtliche Features eines Ant-Buildskripts verwendet werden
 Ein Plugin kann mehrere Targets für unterschiedliche Goals enthalten


Maven – Erweiterungen: Wagon-Provider

 Maven bietet die Möglichkeit Projekt-Artefakte in jede Art von Repository zu
schreiben
 Um spezielle Repositories nutzen zu können, ist es notwendig einen eigenen
Wagon-Provider bereitzustellen
 Damit können Erfordernisse, wie z.B. CVS-Based Repositories oder spezielle
Authentifizierung, abgedeckt werden
 Der Wagon-Provider muss nur vom org.apache.maven.wagon.AbstractWagon
erben
 Es müssen nur die openConnection(), put() und get() Methoden
überschrieben bzw. implementiert werden
 Der Wagon-Provider kann dann als Extension in der entsprechenden pom.xml
konfiguriert und verwendet werden


Verwendung von Maven mit Ant

 Einige Aspekte von Maven können in Ant als gewöhnliche Ant-Tasks verwendet
werden
 Abhängigkeiten können aufgelöst werden; auch das Feature Transitive
Dependencies wird unterstützt
 Projektartefakte können in Repositories deployed werden
 Die Informationen der pom.xml können ausgelesen werden und stehen dann als
Properties zur Verfügung
 Sinnvoll ist es sämtliche Projektinformationen in der pom.xml zu halten, um
solche Metadaten zentral pflegen zu können
 Auch die Verzeichnisstruktur innerhalb eines Projekts könnte der von Maven
nachempfunden werden
 So ist es später kein Problem den Buildprozess auf Maven umzustellen und neue
Teammitglieder finden sich sehr schnell zurecht


Links

 Maven Webseite
http://maven.apache.org/
 FAQs
http://docs.codehaus.org/display/MAVENUSER/FAQs
 MavenUSER
http://docs.codehaus.org/display/MAVENUSER/Home
 Eclipse-Plugin
http://maven.apache.org/eclipse-plugin.html
 Eclipse und Maven
http://maven.apache.org/guides/mini/guide-ide-eclipse.html
 Maven Referenzen (Javadocs, Schema,...)
http://maven.apache.org/ref/current/index.html


Maven2 - Die nächste Generation des Buildmanagements?

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Maven2 - Die nächste Generation des Buildmanagements?

Semelhante a Maven2 - Die nächste Generation des Buildmanagements? (20)

Mais de Thorsten Kamann

Mais de Thorsten Kamann (11)

Maven2 - Die nächste Generation des Buildmanagements?