Apache Ant

Obwohl Ant mittlerweile nicht mehr ganz so populär ist, wird es nach wie vor aktiv weiterentwickelt (das letzte Update ist im April dieses Jahres veröffentlicht worden). Dennoch treten immer wieder zwei zentrale Probleme von Ant in Kommentaren von Entwicklern und Fachartikeln hervor: Zum einen ist XML als sehr hierarchische Auszeichnungssprache denkbar ungeeignet für ein Tool, das auf der Idee des Prozeduralen Programmierens basiert. Zum anderen wird XML in Ant sehr schnell sehr unübersichtlich, wenn es für sehr viele kleinere Projekte gleichzeitig verwendet wird.

Die Vorteile von Ant sind unter anderem die hohe Kontrolle innerhalb des Erstellungsprozesses und die Möglichkeit, es durch Plug-ins zu erweitern. Für das Dependency Management über das Netzwerk wurde das Projekt Apache Ivy in Ant integriert.

Apache Buildr

Im Vergleich zu Ant ist Buildr besser erweiterbar und dadurch als universelles Tool eher geeignet. Dabei spielt natürlich die Flexibilität und die umfangreichen Bibliotheken der verwendeten Script-Sprache Ruby eine große Rolle, die eine Weiterentwicklung und Bereicherung von Buildr durch Plug-ins leichter macht. Weitere Technologien, die bereits von Haus aus unterstützt werden, sind unter anderem JUnit, TestNG, JMock und Emma.

Wie auch Maven oder Ant ist Buildr in erster Linie für Java-Anwendungen gedacht, enthält allerdings auch Compiler für Groovy und Scala – weitere Faktoren, die für Buildr sprechen. Wer sich nicht von Ant trennen will, für den gibt es eine Integration von Buildr in Apache Ant.

Apache Maven

Ganz wie der große Bruder nutzt Maven XML als Sprache für die Build-Spezifizierung. Allerdings ist die Art und Weise, wie der Erstellungsprozess beschrieben wird, völlig anders: Während in Ant sämtliche Befehle für den gesamten Erstellungsprozess minutiös aufgelistet und beschrieben werden müssen, damit die Ausführung erfolgreich ist, können in Maven Projekte in kleinere Teile zerlegt und jedes mit einem eigenen Project Object Model (POM) ausgestattet werden. In den POMs werden dann die Build-Prozesse konfiguriert und anschließend kann ein root-POM geschrieben werden, das die Kompilierung des gesamten Projektes mit einem einzigen Befehl beginnt. Eine revolutionäre Änderung war die Einführung der Möglichkeit, Abhängigkeiten über das Netzwerk herunterzuladen. Dies wurde bei Ant erst mit der Implementierung von Ivy möglich. Wie bei Ant gibt es auch für Maven zahlreiche Plug-ins und dementsprechend die Möglichkeit, Mavens Funktionalität zu erweitern.

Doch auch Maven ist nicht völlig problemlos in seiner Anwendung: Wie in Ant schlägt man sich in Maven mit der Verwendung des sehr strikten und standardisierten XML herum, und die individuelle Anpassung von Zielen beim Erstellprozess ist schwierig. Eine Disziplin, die Ivy sehr viel besser meistert, ist die Verwendung von verschiedenen Versionen der gleichen Bibliothek, was in Maven immer wieder zu Problemen führen kann.

Bazel

Im Vergleich zu Maven und Ant ist Bazel vor allem auf polyglotte Entwicklung ausgelegt, während die Vergleichstools aus dem Hause Apache doch eher auf das Erstellen und Arbeiten mit Java zugeschnitten wurden – dementsprechend sehen auch die jeweiligen Features und Plug-ins dieser Build-Tools aus. Außerdem unterstützt Bazel aufgeteilte Codebasen mit kleineren, wiederverwendbaren Einheiten. Im Vergleich mit Gradle sieht Google die Konfigurationsdateien von Bazel als wesentlich strukturierter an.

Projekte werden in Bazel mittels der BUILD-Sprache beschrieben, die besonders prägnant ist und Projekte als Sets aus verbundenen Bibliotheken, Binaries und Tests definiert. Bazel ist laut Google besonders für die Verwendung in großen Projekten mit einer dementsprechend umfangreichen Codebasis geeignet.

Buck

Während in Maven die sogenannten POMs die Build-Regeln und -definitionen beinhalten, sind sie in Buck in einer Datei Namens BUCK definiert. Um diese Regeln zu definieren, werden eingebaute Python-Funktionen verwendet. Buck ist tatsächlich sehr schnell, dies liegt vor allem an daran, dass Buck sämtliche Abläufe im Build-Prozess optimiert: Zum Beispiel werden keine unnötigen Rebuilds durchgeführt, und in der Standardeinstellung werden ausschließlich First-Order-Abhängigkeiten verwendet. Abgesehen davon ist vor allem der Support für die Android-Entwicklung bei Facebooks Buck hervorzuheben.

Doch auch Buck hat gewisse Nachteile: Einer davon ist, dass die Entwicklung sehr rasant stattfindet. Das ist einerseits gut, allerdings macht es den Einstieg sehr mühsam, da die entsprechenden Dokumentationen und Informationsmöglichkeiten fehlen. Ein Faktor, der auch durch die relativ kleine Community beeinflusst wird. Zudem unterstützt Buck nicht das Betriebssystem Windows. Auch wenn dies für die Zukunft geplant ist, nutzen viele Entwickler und Unternehmen Microsofts OS und haben damit nur schwer die Möglichkeit, Buck effektiv zu nutzen. Schließlich und endlich sorgen alle diese Punkte dafür, dass es für Buck bislang keine Plug-ins gibt und auch die Erweiterbarkeit noch als „sehr schwer“ zu bezeichnen ist.

Gradle

Wie in Buildr wird nicht XML genutzt, sondern eine andere Sprache – allerdings in diesem Fall nicht Ruby sondern eine domänenspezifische Sprache (DSL), die auf Groovy basiert. Skripte neigen deshalb dazu, wesentlich kürzer und klarer formuliert zu sein, als jene für Ant oder Maven. Um die Reihenfolge der auszuführenden Tasks zu bestimmen, verwendet Gradle einen azyklischen gerichteten Graphen (DAG). Für das Dependency-Management wurde anfangs Apache Ivy verwendet, später wurde eine eigene Engine entwickelt.

Im Vergleich zu anderen Tools ist eine immer wiederkehrende Kritik, die (vergleichsweise) niedrige Geschwindigkeit und die massive Auslastung des Zwischenspeichers. Auch die Verwendung der DSL wird nicht von allen Entwicklern als durchweg positiv empfunden: Schließlich bedeutet es eine weitere Programmiersprache nur für die Verwendung des Build-Tools zu lernen.

Pants

Mit Pants lassen sich große Monorepos mit einem sehr umfangreichen und feinkörnigen Abhängigkeitsmanagement erstellen und verwalten. Inkrementelle Kompilationen und Concurrent Task Execution sind ebenfalls wichtige Bestandteile des Build-Tools. Pants ist dabei polyglott und unterstützt eine Vielzahl an Programmiersprachen: Java, Python, JavaScript, Go, Scala, C/C++ und Thrift sind nur einige davon. Die Unterstützung eines Rich-Plug-in-APIs sowie die Möglichkeit, schnelle und reproduzierbare Builds anzulegen, sind weitere Kernelemente.

Pants lässt sich, genau wie Buck und anders als Bazel, in eine Entwicklungsumgebung integrieren. Während Buck sich allerdings in jede IDE gut integrieren lässt, existiert für Pants bisher lediglich ein Plug-in für IntelliJ IDEA. Eine weitere Ähnlichkeit zu Bazel und Buck ist die BUILD-Datei, die mit Python-artigen Befehlen gefüttert wird.

sbt

Kein Alleinstellungsmerkmal, aber durchaus ein wichtiges Feature ist natürlich die native Unterstützung der Scala-Kompilierung und die Möglichkeit, viele Scala-Testframeworks zu verwenden. Build-Beschreibungen werden, ähnlich wie bei Gradle, anhand einer domänenspezifischen Sprache geschrieben – hier allerdings nicht in Groovy, sondern in Scala. Die inkrementelle Kompilierung ist ein weiteres Schlüsselfeature des Tools, genau wie die Unterstützung von Projekten, die sowohl Java als auch Scala enthalten.

sbt ist das Build-Tool der Wahl für die Scala-Community und unter anderem fester Bestandteil des Play Frameworks. Wie bei anderen Tools ist allerdings die Notwendigkeit zur Erlernung einer DSL negativ behaftet. Gerade die DSL von sbt hat den Ruf, sehr kryptisch zu sein, vor allem im Vergleich zum deklarativen XML-Ansatz, der bspw. in Maven verfolgt wird. Wie bei anderen Nischenprodukten, wie etwa Buck, lässt die Anzahl der Plug-ins und der Umfang der Dokumentation zu wünschen übrig.