Geschichte

Maven entstand, weil Java-Projekte, die lose zusammengehörten, untereinander nicht “kompatibel” waren. Jedes Projekt hatte sein eigenes Ant Skript (das meistens auch mehr oder weniger die selben Tasks ausführte), aber dennoch unterschiedlich aufgebaut war. Hinzu kam, dass Depenencies (meistens JAR Dateien) einfach über das Source Repository verwaltet wurden – zwar sehr effektiv und zuverlässig, aber das machte es problematisch für Projekte, Dependencies zu teilen (und eines der Grundprinzipien in der Softwareentwicklung ist DRY: Don’t Repeat Yourself!). Maven wurde entwickelt, einen Standard für die Java Softwareentwicklung zu setzen, Kollaboration einfach zu machen, und gute Praktiken zu fördern.

Aufbau

Hinweis: Ich beschreibe hier Maven Version 1.x. Version 2 ist momentan in Alpha und wird sich in vielerlei Hinsicht erheblich von 1.x unterscheiden!

Im folgenden werde ich parallelen zu Ant ziehen, wenn das sinnvoll ist. In Ant wird der Buildprozess von build.xml gesteuert. Mit Maven sind es drei Dateien, die man kennen muss:

  • project.xml – das Herzstück für ein Maven-Buildsystem. Diese Datei beschreibt Quellcode, Entwicklungsumgebung, benötigte Resourcen (JARs, Plugins), Mailinglisten, Sourcecode Repository, und alle anderen Elemente die zu einem gesunden Softwareprojekt gehören. Diese Datei wird oft mit POM (Project Object Model) bezeichnet.
  • project.properties – optional, aber eigentlich immer erforderlich. Hier werden Aspekte des Projektes konfiguriert, zum Beispiel die JVM Version.
  • maven.xml – Wenn der Rahmen, den Maven vorgibt, nicht flexibel genug ist, können Skripte über diese Datei in das Buildsystem eingeklingt werden – zum Beispiel die Generierung von Artifakten mit XDoclet.

Maven hat eine Plugin Struktur. Viele Plugins werden mit Maven mitgeliefert, aber es gibt auch viele zusätzliche Plugins. Diese müssen nicht installiert werden – wie JARs, werden diese in project.xml definiert und von Maven automatisch heruntergeladen.

Repository

Was habe ich gerade gesagt? Automatisch heruntergeladen?!? Das ist eine der Stärken von Maven. Alle extern benötigten Resourcen brauchen nicht von Hand installiert zu werden. Statt dessen werden diese in build.xml beschrieben zum Beispiel folgendermaßen:

 <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.8</version> </dependency> 

In diesem Beispiel wird das Artifakt “log4j” im Projekt log4j heruntergeladen, Version 1.2.8. Maven sucht die Resourcen unter

http://ibiblio.org/maven/

Die heruntergeladenen Resourcen werden projektunabhängig auf der Workstation des Benutzers gespeichert, unter

$HOME/.maven/repository

Beispielprojekt

Genug Theorie - wie sieht das ganze in der Praxis aus? Ein neues Projekt mit Maven zu erstellen ist sehr einfach. Einfacher, als ein besehendes Projekt zu Maven zu migrieren, aber dazu später mehr. Ich gehe davon aus, dass Maven installiert ist, und wir uns in einem leeren Verzeichnis befinden, wo unser neues Maven-Projekt entstehen wird. Dort führen wir den folgenden Befehl aus:

$ maven genapp

"genapp" erzeugt ein leeres Maven-Projekt. Dieser Befehl ist interaktiv:

 __  __ |  \/  |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~ |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2 Enter a project template to use: [default] Please specify an id for your application:  [app] maven-beispiel Please specify a name for your application:  [Example Application] Maven Beispiel Please specify the package for your application:  [example.app] de.jastram.mavenbeispiel build:start: genapp: ... BUILD SUCCESSFUL Total time: 1 minutes 32 seconds Finished at: Mon Jun 06 14:43:41 EDT 2005 

Wenn wir uns jetzt das Verzeichnis anschauen, werden wir feststellen, dass 10 Unterverzeichnisse und 7 Dateien erzeugt wurden, und ich lege dem Leser ans Herz, diese Verzeichnisstruktur zu untersuchen. Unter anderem wurde ein Einstiegspunkt in die Anwenung und ein paar JUnit-Tests erzeugt.

Um einen besseren Überblick zu bekommen, Erzeugen wir HTML-Dokumentation für unser Projekt:

$ maven site

Es kann eine Weile dauern, bis Maven damit fertig ist. Alle erzeugten Objekte sind unter target zu finden, und die Dokumentation ist unter target/docs - auf jeden Fall clicken und ausprobieren!

Auf jeden Fall auch das Untermenü "Project Reports" erkunden - dort kann der Sourcecode gebrowst werden, Unit Test Ergebnisse untersucht werden, JavaDoc ist verfügbar, und vieles mehr.

Dokumentation

Beeindruckend, was Maven für uns macht. Aber die Optionen und Möglichkeiten sind so vielfältig, dass es anfangs schwierig ist, sich zurechtzufinden. Zum Beispiel, wo kommen die Argumente "genapp" und "site" her, so sind sie dokumentiert?

Zunächst: das Argument ist gar nicht "site", sondern site:site. Aber das Default-Goal (Goal ist das Maven equivalent zu Ant's Target) für das Plugin "site" heißt "site".

Alle Plugins sind auf der Maven Website dokumentiert, und die Dokumentation der Plugins enthält eine Liste der Goals. Außerdem sind dort auch Properties beschrieben, die in build.properties untergebracht werden können. Das site plugin, zum Beispiel, führt eine Reihe von Properties aus, die es erlauben, die Projektseiten per FTP auf einen Webserver hochzuladen (per site:deploy Goal).

Weiterhin lohnt es sich, die Dokumentation für build.xml, den Project Descriptor, durchzulesen.

Und noch ein wichtiger Hinweis: Maven benutzt nicht Ant, sondern Jelly als Skript-Sprache. Allerdings ist es nicht schwierig, per Jelly Ant-Skripte auszuführen.

IDE-Integration

Maven hat Goals um Projektdateien für IDEs zu generieren. Zum Beispiel erstellt der folgende Befehl ein Eclipse-Projekt:

$ maven eclipse

Love and Hate

Ein eindrucksvolles Werkzeug - warum gibt es doch eine Reihe von Leuten, die Maven hassen? Diskussionen zum Thema gibt es genug, aber hier sind meine Gedanken und Kommentare in der Hoffung, die Frustration mit Maven zu minimieren:

  • Maven ist noch nicht stabil - es hat lange gedauert, bis sich Version 1 stabilisiert hatte, und im Moment werden viele Fehler in Version 2 korrigiert - aber 2 ist auch noch im Alpha-Stadium. Wenn viele Änderungen zur Frustration fürhen können, rate ich von Maven ab.
  • Anfangs weniger Einfluß auf die Projektstruktur - Maven gibt eine gute Projektstruktur vor, aber die gefällt bestimmt nicht jedem. Die kann zwar geändert werden, aber man muss sich schon eine Weile mit Maven beschäftigen, um das ohne Frustration tun zu können. Ant ist wesentlich einfacher den eigenen Bedürfnissen anzupassen. Aber die Maven Projektstruktur besteht aus einem guten Grund - viele schlaue Leute haben sich viele Gedanken darüber gemacht. Natürlich ist es akzeptabel von dieser Struktur abzuweichen, aber ich würde mir bei jeder Änderung gut überlegen, ob die Änderung die Projektstruktur wirklich verbessert.
  • Migration von Altanwendungen lohnt sich oft nicht - ein bestehendes Projekt mit einem gut dokumentierten, funktionierendem Ant-Skript sollte nur dann zu Maven überführt werden, wenn es wirklich einen guten Grund gibt. Durch die eigenwillige Projektstruktur und die nicht elegante Ant Integrierung kann auch das zur Frustration führen. Aber zum Beispiel die Integration mit anderen Maven-Projekten wäre ein guter Grund.
2 Comments
  1. Der Artikel ist nicht schlecht, danke.

  2. Ja, vielen Dank für das Tutorial, es war wirklich hifreich. Ich hätte aber gerne mehr Info. Danke für die Mühe.