Build-Prozess für Java-Anwendungen: So setzt man Maven ein

Nun weiß das Maven-Projekt, welche Bibliotheken es benötigt, und der Build-Prozess kann schon fast gestartet werden. Nur noch zwei Dinge müssen Maven mitgeteilt werden: einmal, dass der Quellcode als Java 1.5 erzeugt und wie er ausgeführt werden soll. Diese Informationen werden im Abschnitt build eingetragen.

Als Erstes wird im build-Bereich der endgültige Name für den fertigen Code eingegeben. Dann werden die Einstellungen für verwendete Plugins festgelegt. Mithilfe von Plug-ins kann Maven erweitert werden. Diese müssen nicht installiert werden, sondern man kann sie einfach so benutzen, weil Maven sie gegebenenfalls aus seinem eigenen Repository abruft. Das erste Plugin, das eingerichtet wird, ist das maven-compiler-plugin. Jetzt muss Maven nur noch mitgeteilt werden, dass es für Java 1.5 kompilieren soll, indem man zwei Konfigurationseigenschaften setzt: source und target.

Und schließlich kommt noch ein Plugin namens Cargo zum Einsatz, das dafür sorgt, dass die fertige Webanwendung zur Ausführung in einen entsprechenden Container verpackt wird.

Damit steht dem Build des Projekts nichts mehr im Wege. Das Ziel von Maven darin besteht, das Artefakt in das Repository zu installieren. Daher werden beim Aufrufen des entsprechenden Befehls automatisch alle erforderlichen Schritte ausgeführt.

Dies führt erst einmal zu ausgiebigem Herunterladen, weil Maven sich alle benötigten Plugins und Artefakte aus den zentralen Repositories besorgt. Aber ein Artefakt fehlt auf jeden Fall, nämlich das DWR-Artefakt. Maven wird irgendwann mit einer bemerkenswert informativen Fehlermeldung abbrechen:

Man muss also DWR2.0M3 herunterladen und es in das Repository installieren. DWR2.0M3 findet sich nicht auf der DWR-Hauptwebsite, die Datei dwr.jar kann aber von Java.net heruntergeladen werden. Danach ist der von Maven vorgeschlagene Befehl auszuführen, wobei der Pfad zu dwr.jar entsprechend angepasst werden muss. Nun kann der zweite Versuch mit install gestartet werden:

Wieder wird heruntergeladen, Code kompiliert, Unit-Tests durchgeführt, die Webanwendung zusammengestellt und die entstandene war-Datei in das lokale Maven-Repository installiert. Die Ergebnisse der Arbeit finden sich im neu erstellten target-Verzeichnis. Natürlich wird man die Anwendung auch gleich einmal ausprobieren wollen. Hier kommt nun das Cargo-Plugin ins Spiel. Standardmäßig lädt Cargo einen Embedded-Jetty-5.x-Webserver herunter, richtet diesen ein und führt die Haupt-war-Datei aus. Hierzu muss man Cargo mit dem Ziel start aufrufen:

Wieder werden die erforderlichen Artefakte heruntergeladen. Das Ganze sollte mit folgender Meldung enden:

Jetzt gibt man in seinem Webbrowser die folgende Adresse ein: http://localhost:8080/todotasks/, wo die entsprechende Webanwendung (todotasks) laufen sollte.

Eigentlich war die pom.xml-Datei nicht besonders umfangreich, aber es gibt damit einen Build-Prozess, der den grundlegenden Lebenszyklus abdeckt. Ein Blick in das target-Verzeichnis zeigt ein Verzeichnis surefire-reports mit Berichten zu allen durchgeführten Unit-Tests. Das ist aber nicht alles, was generiert werden kann. Zum Beispiel kann Maven auch mit dem Ziel site ausprobiert werden:

Dies generiert eine Vorlage für eine Website, basierend auf dem Projekt und gespeichert unter target/site. Wenn man die Datei index.html in seinem Browser öffnet, wird einem das Layout von vielen Apache-Projekten her vertraut vorkommen. In diesem Fall sind neben der Seite mit den Abhängigkeiten nur auf wenigen Seiten Inhalte vorhanden. Aber es ist gut zu wissen, dass Maven auch mit solchen Prozessen zurechtkommt.