Eine Umfrage auf JAXenter bestätigt, dass der Markt der Build-Systeme für Java-Projekte sich vor allem auf die schon altbewährten Ant und Maven aufteilt. Auf einem guten dritten Platz der Umfrageergebnisse befindet sich bereits der Neuling Gradle (Ergebnis: 12 %). Interessant ist auch, dass 4 % der Umfrageteilnehmer angegeben haben, kein Build-System einzusetzen. Somit soll kurz die Frage erlaubt sein, wann und warum es überhaupt Sinn macht, ein Build-System im Projekt einzusetzen.
Die hauptsächliche Entwicklung eines Java-Projekts erfolgt in einer Entwicklungsumgebung (IDE) wie Eclipse, Netbeans oder IntelliJ IDEA. Ständig führt der Entwickler die drei wichtigen Schritte aus: Edit, Compile und Run. Mit diesem Entwicklungszyklus sind Änderungen schnell sichtbar, und der Entwickler kann die Anwendung direkt aus der Entwicklungsumgebung heraus starten. Je größer und komplizierter die Anwendung wird, umso mehr Einstellungen sind erforderlich, um die Anwendung zu starten. Sobald es aber daran geht, dass Teammitglieder mit verschiedenen Entwicklungsumgebungen arbeiten bzw. die Anwendung auf ein anderes System gebracht werden muss, wird eine Unabhängigkeit von der Entwicklungsumgebung benötigt. Laufzeiteinstellungen für ein Projekt sollten deswegen nicht in einer lokalen Entwicklungsumgebung festgehalten werden. Dies erschwert die schnelle Übernahme auf ein anderes System und ist der Ansatzpunkt für ein Build-System. Selbst bei wachsender Quellcodebasis und steigender Anzahl der Entwickler kann durch das Build-System sichergestellt werden, dass die Zielartefakte unabhängig von einem Entwicklerrechner erzeugt werden können. Die Möglichkeiten, die sich durch solch ein System eröffnen, sind mannigfaltig.
Die drei Systeme Ant, Maven und Gradle werden anhand eines Beispielprojekts einem Vergleich unterzogen. Alle drei Systeme (Ant ab Version 1.6.1) basieren auf der Apache License Version 2.0. Der Artikel hat nicht den Anspruch, alle Systeme vollständig zu erklären, die wichtigsten Konzepte werden aber erläutert.
Die Spielregeln
Um einen guten Eindruck der drei Probanden zu bekommen, wird die Vorstellung anhand eines Beispiels mit typischen Projektanforderungen durchgeführt. Es wurde versucht, einige der typischen Anforderungen an den Build-Prozess zu definieren. Eine vollständige Abdeckung kann dieser Artikel aber nicht leisten. Größere Projekte sind häufig in Module (Teilprojekte) aufgeteilt, dies spiegelt das Demoprojekt durch drei Module wieder. Das Modul core stellt dabei eine Basisbibliothek dar, die von den anderen beiden Modulen wiederverwendet wird. Diese Module tragen die Namen richclient und webclient. In Abbildung 1 ist die Abhängigkeit zwischen den drei Modulen visualisiert. Die Projekte verwenden dabei unterschiedliche Bibliotheken. Alle drei Projekte enthalten Unit-Tests auf der Basis von JUnit 4. In den Testklassen werden Bibliotheken eingesetzt, die teilweise nur in diesen benötigt werden und somit nicht im Zielartefakt (war-Archiv beim Projekt webclient) landen sollen.
Die Verzeichnisstruktur des Demoprojekts (Abb. 2) entspricht der Standardverzeichnisstruktur eines Maven-Projekts. Diese hat sich inzwischen in vielen Java-Projekten etabliert und bewährt.
Um die Anforderungen im weiteren Verlauf wieder zu identifizieren, sind sie durchnummeriert und in der nachfolgenden Tabelle kurz erläutert.
| Nummer | Beschreibung |
|---|---|
| 1 | Jedes der drei Teilprojekte kann im Build-Prozess einzeln erzeugt werden. Zusätzlich soll aber auch das Gesamtprojekt über einen einzigen Aufruf erzeugt werden können. |
| 2 | Aus dem Projekt core soll ein JAR-Archiv erzeugt werden. Dieses JAR-Archiv soll eine angepasste Manifest-Datei enthalten. Der Name der erzeugten Datei ist core-1.0.0.jar. Die Version 1.0.0 kann konfiguriert werden. |
| 3 | Aus dem Projekt richclient soll ein JAR-Archiv erzeugt werden. Auch dieses JAR-Archiv enthält eine angepasste Manifest-Datei. Der Name der erzeugten Datei ist richclient-1.0.0.jar. Für die Erzeugung des Projekts soll die Bibliothek core-1.0.0.jar eingebunden werden. |
| 4 | Aus dem Projekt webclient soll ein WAR-Archiv erzeugt werden. Der Name der erzeugten Datei ist webclient-1.0.0.war. Für die Erzeugung des Projekts soll die Bibliothek core-1.0.0.jar verwendet werden. In der erzeugten Archivdatei soll im Verzeichnis WEB-INF/lib die Datei core-1.0.0.jar liegen. |
| 5 | Alle Projekte enthalten Unit-Tests auf Basis von JUnit 4. Diese Tests sollen vom Build-Prozess ausgeführt werden. Das Projekt webclient benötigt für die Kompilierung und die Unit-Tests servlet-api.jar und das Spring Framework. Diese Bibliotheken dürfen nicht im Zielarchiv enthalten sein. |
| 6 | Auf den Projekten soll Checkstyle ausgeführt werden. |
Bei der Erfüllung der Anforderungen soll den Build-Systemen Hilfe zugestanden werden. Wenn eine Anforderung nicht mit der Grundausstattung des Build-Systems umgesetzt werden kann, wird versucht, sie mit vorhandenen Erweiterungen umzusetzen.
Wahrscheinlich gibt es sehr wenige Projekte, die ohne externe Bibliotheken auskommen. Warum auch? Das Rad muss und soll auch nicht ständig neu erfunden werden. Sobald gleiche Bibliotheken in mehreren Projekten eingesetzt werden, stellt sich die Frage, wie sie sinnvoll verwaltet werden sollen. Der Ansatz der Speicherung der Bibliotheken im jeweiligen Versionsverwaltungssystem des Projekts ist möglich, aber bei steigender Anzahl der Projekte nicht sehr effizient. Hinzu kommt noch, dass viele Bibliotheken selbst wieder von anderen Bibliotheken abhängen, das wird als transitive Abhängigkeit bezeichnet.
Um zu vermeiden, dass die Verwaltung von externen Bibliotheken (Abhängigkeiten) nicht komplett selbst gemacht werden muss, existiert das Konzept des Dependency Managements bei vielen Build-Systemen.
Was sind Ihre Erfahrungen mit Ant, Maven und Gradle?
In einer interaktiven Vergleichsaktion zwischen Maven, Ant und Gradle möchten wir die Eigenarten dieser drei Build-Tools herausarbeiten und besonders auch das Erfahrungswissen aus Ihrer eigenen Praxis, liebe JAXenter-Leser, zur Geltung kommen lassen! Jason van Zyl (Maven), Jan Matèrne (Ant) und Hans Dockter (Gradle) stellen sich dabei dem Feedback aus der Community und beantworten direkt Ihre Fragen!Teilen Sie uns Ihre Erfahrungen mit den Buildtools anhand der folgenden Fragen mit:
- Mit welchen Build-Systemen haben Sie in Ihrer Praxis bereits Erfahrungen gesammelt?
- Wo sehen Sie die Stärken Ihres bevorzugten Build-Systems?
- Wo sehen Sie Schwachpunkte der anderen Build-Systeme?
- Welche Fragen haben Sie an Jason van Zyl (zu Maven), Hans Dockter (zu Gradle) und Jan Matèrne (zu ANT)?
Senden Sie Ihren Erfahrungsbericht einfach direkt an die JAXenter-Redaktion!
Wir sind gespannt auf Ihr Feedback!
