Tooltime

8 Build-Tools im Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt

Dominik Mohilo

©Shutterstock / cybrain

Nichts macht Entwickler stolzer, als wenn der Sourcecode komplett vorliegt und man nur noch wenige Klicks vom fertigen Programm entfernt ist. Um die Transformation von Code in ein ausführbares Anwendungsprogramm zu erleichtern, gibt es Build-Tools, die den Erstellungsprozess übernehmen und neben der Code-Kompilierung u.a. die Einbindung der nötigen Bibliotheken erledigen. Doch Build-Tools gibt es viele – welches ist das richtige für Ihr Projekt? Wir haben uns 8 bekannte Tools angesehen, um Ihnen die Entscheidung ein wenig zu erleichtern.

Apache Ant

ant-quad
Entwickler: Apache Software Foundation
Lizenz: Apache Lizenz 2.0
Aktuelle Version: 1.9.7
Link: http://ant.apache.org
Beinahe 16 Jahre ist es her, seit mit Ant das erste “moderne” Build-Tool aus dem Apache-Projekt Tomcat hervorging. In vielerlei Hinsicht ist Ant dem Urvater aller Build-Tools, Make, gleich. Im Gegensatz zum Unix-Build-Tool wird Ant allerdings mit Java ausgeführt. Ein weiterer Unterschied ist, dass in Ant XML genutzt wird, um den Build-Prozess zu beschreiben.

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

buildr-quad
Entwickler: Apache Software Foundation
Lizenz: Apache Lizenz 2.0
Aktuelle Version: 1.4.25
Link: http://buildr.apache.org
Während Nutzer von Maven und Ant sich ganz auf die Möglichkeiten der Auszeichnungssprache XML verlassen müssen, setzt Apache Buildr auf eine vollständige Scripting-Sprache, nämlich Ruby. Buildr basiert dabei auf Rake, einem Build-System für Ruby. Dennoch verwendet Buildr auch Muster von Maven, etwa das automatische Artefakt-Management. Außerdem ist Buildr von Haus aus bereits mit Maven-Repositories kompatibel.

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.

Buildr Projektstruktur / Quelle: Apache Buildr Projekt

Buildr Projektstruktur / Quelle: Apache Buildr Projekt

Apache Maven

maven-quad
Entwickler: Apache Software Foundation
Lizenz: Apache Lizenz 2.0
Aktuelle Version: 3.3.9
Link: https://maven.apache.org
Einer der Grundsätze, denen sich die Macher von Apache Maven verschrieben haben, ist, den Build-Prozess möglichst einfach zu halten. Das entspricht der allgemein anerkannten Meinung, dass man vom besten Build-Tool möglichst nichts mitbekommt, während schlechte Build-Tools Fehler produzieren oder nicht richtig funktionieren. Als Maven 2004 released wurde war der Hauptgrund allerdings, die vielen kleinen Probleme von Ant zu lösen.

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.

Apache Maven Abhängigkeitsstruktur / Quelle: Apache Maven Projekt

Apache Maven Abhängigkeitsstruktur / Quelle: Apache Maven Projekt

Bazel

bazel-quad
Entwickler: Google
Lizenz: Apache Lizenz 2.0
Aktuelle Version: 0.2 (Beta)
Link: http://www.bazel.io
Die Geschichte von Bazel begann, als die Entwickler von Google merkten, dass die großen Makefiles, die sie zur Softwareentwicklung nutzten, viel zu schwerfällig, langsam und fehleranfällig waren. Logischerweise wurde dadurch die Produktivität der Google-Entwickler gehemmt, sodass die Arbeit an einem eigenen Tooling begonnen wurde.

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.

Das Bazel-Dashboard befindet sich noch in der Entwicklung / Quelle: Bazel.io

Das Bazel-Dashboard befindet sich noch in der Entwicklung / Quelle: Bazel.io

Buck

buck-quad
Entwickler: Facebook
Lizenz: Apache Lizenz 2.0
Aktuelle Version: 2016.04.18.01
Link: https://buckbuild.com
Buck setzt, ganz ähnlich wie Bazel, auf Geschwindigkeit und die Unterstützung von kleineren Projektteilen, ähnlich wie Maven. Es wurde von ehemaligen Google-Entwicklern entwickelt und genau wie Pants oder Bazel selbst ganz auf die Ansprüche des jeweiligen Unternehmens angepasst. Erstellt wurde und wird Buck, obwohl es ja selbst ein Build-Tool ist, allerdings mit einem anderen Tool: Apache Ant. Dies ergibt, laut den Entwicklern, mehr Sinn, als ein sogenanntes Self-hosting System, da diese komplizierter zu warten und debuggen sind.

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.

Building mit Buck / Quelle: Buckbuild

Building mit Buck / Quelle: Buckbuild

Gradle

gradle-quad
Entwickler: Gradle Inc.
Lizenz: Apache Lizenz 2.0
Aktuelle Version: 2.13
Link: http://gradle.org
Gradle basiert auf dem gleichen Konzept wie Apache Ant und Maven und vereint in sich gute Teile beider Tools: Von Ant übernahm man die Flexibilität, von Maven die Benutzerfreundlichkeit. Gradle war dabei so erfolgreich, dass sogar Google es als hauptsächlich verwendetes Build-Tool für das Betriebssystem Android verwendete.

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.

Gradle in Eclipse / Eclipse Marketplace

Gradle in Eclipse / Eclipse Marketplace

Pants

pants-quad
Entwickler: Twitter
Lizenz: Apache Lizenz 2.0
Aktuelle Version: 1.0.1
Link: http://www.pantsbuild.org
Wie Buck (Facebook) und Bazel (Google) ist Pants ein Homebrew eines großen Unternehmens – in diesem Falle Twitter. Die Entwicklung von Pants begann bereits 2011, am 1. Mai 2016 erschien dann das erste Major Release. Anders als bei anderen Unternehmen setzt Twitter für seine Codebasis auf ein einziges großes Repository (monorepo). Aus Skalierungsgründen waren die Build-Tools wie Apache Ant und Maven nicht in Frage, Buck und Bazel waren closed source, also nicht frei verfügbar – ein eigenes Build-Tool musste her.

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

sbt-quad
Hersteller: Lightbend Inc.
Lizenz: BSD Lizenz
Aktuelle Version: 0.13.11
Link: http://www.scala-sbt.org
Wie auch Buildr und Gradle ist auch sbt ein Build-Tool nach dem Vorbild von Maven und Ant. Es ist in Scala geschrieben und – wenig überraschend – für das Bauen von Java- und Scala-Projekten entwickelt worden. Wie Ant nutzt es für das Dependency-Management Apache Ivy und unterstützt somit Repositories im Maven-Format.

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.

Aufmacherbild: Designing, engineering, business planning and project development.von Shutterstock / Urheberrecht: cybrain

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare
  1. Peter2016-06-11 13:16:19

    Im Einleitungstext heißt es, Zitat: "Doch Build-Tools gibt es viele – welches ist das richtige für Ihr Projekt?"

    Diese Frage wird in diesem Artikel nicht beantwortet. Es werden lediglich einige Vor- und Nachteile der einzelnen Build-Tools erläutert. Liebe Redakteure, ihr solltet den Lesern nicht mehr Antworten versprechen als ihr zu halten in der Lage seid. Bei mir hinterlässt das jedenfalls einen schlechten Eindruck.

    1. Dominik Mohilo2016-06-13 09:35:34

      Hallo Peter,

      Sie haben insofern recht, dass wir die Frage, welches Build-Tool das richtige für den jeweiligen Leser ist, in dem Artikel tatsächlich nicht beantworten. Das können wir auch gar nicht, wir kennen ja nicht sämtliche Projekte unserer Leser. Wir haben den Anlesetext ein wenig angepasst, um hervorzuheben, dass es sich hierbei lediglich um einen Vergleich handelt, der die Entscheidungsfindung erleichtern soll, keinesfalls aber den Anspruch hat, eine allgemeingültige Antwort parat zu haben.

      Liebe Grüße,
      Dominik Mohilo

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.