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.