Als Entwickler von Softwareprojekten stellt man schnell fest, dass im Rahmen moderner Software-Entwicklung eine Menge an Arbeitsschritten anfällt, die zu verschiedenen Zeitpunkten der Entwicklung und des Build-Prozesses zu erledigen wären. Diese kann man in folgende Gruppen einteilen:
• Vorbereitende Schritte
• Kompilieren
• Prüfen der Codequalität
• Erstellen der Dokumentation
• Verpacken/Ausliefern der Software
• Installation
Schon bei relativ kleinen Projekten fallen diese Schritte meist an, und die Erfahrung zeigt, dass eine Automatisierung auf jeden Fall sinnvoll ist. Andernfalls schleichen sich Fehler in den Ablauf ein oder manche Schritte werden gar nicht oder zu selten durchgeführt, weil sie händisch als lästig empfunden werden.
Verschiedene Methoden, beispielsweise aus traditioneller Unix-Software-Entwicklung (Shell-Scripts, GNU Make), könnten einige dieser Aufgaben zwar auch erledigen, deren Komplexität, mangelhafte Portabilität und Unterstützung moderner Tools schliessen sie in der Praxis aber aus.
Im Java-Umfeld haben sich mit Ant und Maven zwei Apache-Projekte etabliert, die man mittlerweile sogar als De-Facto-Standard bezeichnen kann.
Apache Ant ist eines der ältesten und bekanntesten Projekte im Umfeld der Automatisierung von Java-Build-Prozessen. Ant ist im wesentlichen ein «Werkzeugkasten». Mitgeliefert werden etwa 150 verschiedene dieser Werkzeuge, Tasks genannt. Dazu gehören Tasks wie Copy, Java oder Javac. Entsprechend bietet Ant also ein durchaus breites Feld an Möglichkeiten. Sollten die mitgelieferten Tasks nicht ausreichen, kann man Tasks von anderen Projekten verwenden oder eigene entwickeln.
Die Logik von Ant ist auch einfach zu verstehen. Für ein Projekt legt man mit der build.xml eine zentrale Konfigurationsdatei an, in der die durchzuführenden Aufgaben angegeben werden. Diese werden üblicherweise in sogenannten Targets gruppiert. Codebeispiel 1 zeigt einen Ausschnitt eines einfachen Beispiels.
Mit dem Tag < project > wird ein Projekt definiert. Verschiedene Projekteigenschaften können dynamisch gehalten werden, indem man sie in eine externe Datei (im Beispiel build.properties genannt) speichert. Als nächstes wird der Klassenpfad festgelegt. Das angenehme hier ist, dass Ant automatisch den Klassenpfad anhand des angegebenen Filesets zusammenbaut; im konkreten Beispiel werden alle Java-Archive eingebunden, die sich im Verzeichnis lib befinden. Danach sind drei Targets definiert, die voneinander abhängig sind. Das Standard-Target ist laut Definition dist. Wird also auf der Kommandozeile im Projekt-Root-Verzeichnis ant aufgerufen, sucht Ant nach der Konfigurationsdatei build.xml und führt automatisch das Standard-Target, also dist, aus. Dieses ist aber abhängig von clean, compile und javadoc. Daher werden zunächst diese ausgeführt. Compile ist wiederum von init abhängig, was sich beliebig fortsetzen lässt. Mit dieser Logik kann man also den Build-Prozess automatisieren und zusammengehörende Aktivitäten gruppieren.
So gut Ant geeignet ist, um typische Build-Aufgaben zu automatisieren, so zeigen sich mittlerweile doch einige konzeptionelle Nachteile des Ant-Ansatzes. Arbeitet man an verschiedenen Projekten, so stellt man fest, dass man eigentlich immer wieder sehr ähnliche Build-Abläufe erstellt und die Wiederverwendbarkeit einer Konfigurationsdatei sich auf Copy-und-Paste-Vorgänge beschränkt. Auch ist das Anbieten eines reinen Werkzeugkastens nicht ganz unproblematisch, da dessen Flexibilität unter Umständen mehr schaden als nutzen kann, wenn beispielsweise Best Practices zur Benennung von Verzeichnissen nicht eingehalten werden müssen. Diesem Problem widmet sich Apache Maven.
Maven ist ein Projekt das dem Prinzip «Convention over Configuration» folgt. Maven ist im Gegensatz zu Ant kein einfacher Werkzeugkasten, sondern vielmehr eine Sammlung von Best Practices, die in Software gegossen wurde. Dies bedeutet, dass Maven eine Reihe von Basisvorgaben macht, die sich aus der langjährigen Praxis vieler Software-Entwickler als sinnvoll herausgestellt haben. Bleibt man bei diesen, lässt sich ein neues Projekt sehr leicht erstellen, und auch neue Entwickler finden sich in diesen De-Facto-Standards wieder leicht zurecht.
Archetypen, die man auch selbst definieren kann, erlauben das Anlegen neuer Basis-Projekte oder anderer Artefakte. Dies ist besonders günstig, um beispielsweise Firmenvorgaben umzusetzen. Dem Anfänger erleichtern die Archetypen natürlich auch den Einstieg in Maven, da er im Gegensatz zu Ant mit einer Anfangskonfiguration beginnen kann.
So erstellt Maven auf Wunsch auch elementare Projektstrukturen, beispielsweise mit einer Java-Klasse, zugehörigem Unit-Test und der passenden Konfiguration.
Das Pendant zur Konfigurationsdatei build.xml aus Ant ist in Maven das Project Object Model, das in der Datei pom.xml vorgefunden werden kann (siehe Codebeispiel 2). Die pom.xml illustriert einen wesentlichen konzeptionellen Unterschied zu Ant: Es werden hier keine Abläufe definiert, sondern vielmehr Ziele und Abhängigkeiten. Im Beispiel sieht man, dass Name, Paket und Version des Programms definiert werden sowie Abhängigkeiten von Bibliotheken. Diese Definition reicht schon aus, um einen Maven Build Lifecycle zu starten. Ein solcher Maven Build Lifecycle besteht nach Maven-Definition aus den verschiedenen Schritten, die am Anfang des Artikels betrachtet wurden und teilweise voneinander abhängig sind.
Ruft man also auf der Kommandozeile mvn test auf, werden die Vorbereitungsschritte durchgeführt, abhängige Bibliotheken geladen, der Klassenpfad vorbereitet, kompiliert und die Unit-Tests ausgeführt. Hält man sich also an die Maven-Konventionen, ist ein solches Projekt sicherlich überschaubarer und einfacher als ein entsprechendes Ant-Projekt. Auch ist die Build-Logik offenbar portabler als bei Ant-Projekten.
Dieses einfache Beispiel kratzt jedoch nur an der Oberfläche von Mavens Fähigkeiten. Im Gegensatz zu Ant wird Funktionalität hier nicht über Tasks definiert, sondern über Plug-ins, die sich an bestimmten Stellen im Build-Vorgang einhängen können. Wird ein neues Plug-in benötigt, so wird dieses automatisch von Maven geladen und installiert. Dies funktioniert sehr ähnlich wie die Definition von Abhängigkeiten bei Artefakten. Plug-ins werden in verschiedenen Projekten entwickelt, beispielsweise bei Apache oder Codehaus.
Ein weiterer wesentlicher Vorteil von Maven im Vergleich zu Ant ist die Verwaltung von Bibliotheken und Abhängigkeiten. In Maven deklariert man, dass beispielsweise eine bestimmte Hibernate-Version benötigt wird. Maven lädt dann die entsprechende Version automatisch von einem Server herunter und überprüft, welche weiteren Bibliotheken Hibernate benötigt, um auch diese zu laden und einzubinden.
Alle verwendeten Versionen werden in einem zentralen Verzeichnis auf dem Rechner nach Versionen abgelegt und nur neu vom Server geladen, wenn eine andere Version benötigt wird.
Soll ein altes Projekt von Ant auf Maven migriert werden oder findet man noch nicht für alle benötigten Schritte Plug-ins, so kann man entweder Ant-Tasks in Maven verwenden oder eigene Plug-ins für Maven schreiben.
Ant ist nach wie vor ein sehr häufig verwendetes Tool und bietet breite Unterstützung in verschiedenen Entwicklungsumgebungen. Manche IDEs wie Netbeans definieren im Gegensatz zu Eclipse überhaupt kein eigenes Projekt-Dateiformat, sondern verwenden direkt Ant-Build-Dateien.
Aber auch Maven holt in der Tool-Unterstützung auf. Maven selbst kann Projektdateien für verschiedene IDEs wie Eclipse aus dem POM erstellen. Aber auch eigene IDE-Plug-ins wie mevenide sind mittlerweile verfügbar.
Alexander Schatten (alexander@schatten.info) ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien.
