Gradle

Ein kompakter Einstieg in das Build-Management-System

Joachim Baumann

• Publisher: dpunkt
• Year: 2013
• ISBN:
  9783864913372
• Edition: 1
• Topic: Informatica
• Subtopic: Elaborazione visiva dei dati

Gradle ist ein modernes Build-Management-System, das auf Groovy basiert und sich immer mehr zu einer Konkurrenz für bestehende Tools entwickelt. Gradle kann sehr gut auf Spezifika der eigenen Umgebung und der eigenen Probleme angepasst werden und ist in der Lage, auch komplexere Builds mit geringem Aufwand zu unterstützen. Das Buch demonstriert die praktische Verwendung von Gradle in Szenarien unterschiedlicher Komplexität und ermöglicht so einen schnellen Einstieg. Auch komplexe Verwendungen wie in einem Continuous-Build-Szenario werden betrachtet.

1 Einleitung

Das Thema Build-Management gibt es, seit es zu umständlich ist, alle Quelltexte eines Programms von Hand dem Compiler und in Folge dem Linker zu übergeben, um ein Programm oder eine Bibliothek zu erzeugen. Die erste Lösung für das Problem waren Skripte, die systemabhängig waren und damit spezifisch für jede Systemplattform geschrieben werden mussten.

make

Das erste verbreitete Build-Management-Werkzeug

Das erste Build-Management-Werkzeug, das größere Verbreitung erlangte, war das Werkzeug make, das als Teil von Unix mitgeliefert wurde. Dieses verwendete eine Datei (das Makefile), die alle Schritte beschrieb, die zur Erzeugung des Programms nötig waren. Auf jedem System, das über das Programm make verfügte, konnte damit das Makefile ausgeführt werden. Der Erfolg von make war so groß, dass es für fast jede Plattform (inklusive MS Windows) eine Version des Programms gibt.

Was damit jedoch nicht gelöst war, war die Auflösung systemabhängiger Namen von Werkzeugen und Bibliotheken und der Orte, an denen sie auf spezifischen Systemen zu finden waren. Auch systemspezifische Compiler-Optionen wurden nicht erfasst.

Dies führte Anfang der 90er-Jahre zu der Entwicklung und Durchsetzung von weiteren Programmen wie zum Beispiel autoconf oder imake (Teil von X11), die diese systemspezifischen Werte bestimmen und ein systemspezifisches Makefile generieren konnten.

Ant

Als 1995 Java die Bühne betrat, war die Situation einigermaßen stabil, und zu Beginn wurden die zur Verfügung stehenden Werkzeuge zur Übersetzung von Java-Programmen verwendet. Sehr schnell stellte sich allerdings die Frage, ob ein in Java geschriebenes Build-Management-System nicht vorteilhaft sein könnte, da das JDK für die Übersetzung ja ohnehin vorhanden sein musste.

Ant war richtungsweisend für Java-Umgebungen.

Es gab verschiedenste Ansätze im Java-Umfeld, erfolgreich und richtungsweisend war Ant (»Another neat tool«), das eine Beschreibung der Schritte für die Erzeugung des Java-Programms in Form einer XML-Datei akzeptierte (erstes Erscheinen mit der Version 1.1 in 2000). Ant setzte sich sehr schnell für alle Java-basierten Programme durch und machte die Komplexität von make und den zugehörigen Werkzeugen überflüssig. Außerdem konnte Ant durch Extensions zusätzliche Funktionalität erhalten.

Ant entstand im Rahmen der ersten Referenzimplementierung eines Servlet-Containers durch Sun, die später unter dem Namen Apache Tomcat weiterentwickelt wurde.

Was aber Ant noch fehlte, waren Funktionen wie eine Abhängigkeitsund Versionsverwaltung für Java-Archive oder die Idee eines Build-Prozesses, der aus verschiedenen, klar getrennten Phasen besteht, um die nötigen Schritte zur Erzeugung des Resultats durchzuführen.

Maven

Maven adressiert fehlende Funktionalitäten und Konzepte in Ant.

Diese Hauptpunkte adressiert Maven, das als Build-Management-System sowohl einen Prozess in Form eines Lebenszyklus mit aufeinanderfolgenden Phasen definiert als auch ein ausgefeiltes System zur Verwaltung und Versionierung von Abhängigkeiten (Java-Archiven) hat, die bei Internet-Verbindung automatisch lokal heruntergeladen werden können (Erscheinen der Version 1.0 in 2004). Hierzu stellt Maven ein globales Archiv (das Maven-Repository, siehe [Maven-Repository]) zur Verfügung, in dem seit 2006 so gut wie alle öffentlichen Java-Archive zum Zugriff bereit liegen.

Um die Funktionalität zu erweitern, können Plug-ins für die verschiedenen Phasen registriert werden. Maven führt dann die jeweilige Implementierung in der entsprechenden Phase aus.

Maven verfolgt einen deklarativen Ansatz.

Maven folgt anders als Ant einem deklarativen Paradigma: Anstatt zu sagen, wie etwas gemacht werden soll, reicht es aus zu sagen, was erreicht werden soll. Hierfür wird eine Spezifikation in Form einer XML-Datei verwendet (das POM oder Project Object Model). Damit dies funktioniert, muss es Konventionen geben, die für die Ausführung der Schritte verwendet werden. Ein Beispiel hierfür sind die Orte, an denen bei Maven Quelltexte (src/main/java) und Tests (src/test/java) zu finden sind. Auch Maven bietet die Möglichkeit, die Funktionalität durch Plug-ins zu erweitern, die ihre jeweils eigenen Konventionen mitbringen.

Da Maven sein Leben als Werkzeug im Umfeld des Apache-Projekts Jakarta Alexandria begann und in Folge für alle Apache-Projekte eingesetzt werden sollte, bilden die durch Maven definierten Pfade die Vorgaben für Apache-Projekte ab.

Ein großer Nachteil von Maven ist hierbei, dass sowohl der Prozess als auch die Konventionen sehr rigide sind. Das führt zwar dazu, dass jedes mit Maven aufgesetzte Projekt gleich aussieht, es sorgt aber auch dafür, dass das Build-Management früher oder später mit der Infrastruktur kollidiert.

Um das Problem der Abhängigkeits- und Versionsverwaltung bei Ant zu adressieren, wurde das Werkzeug Ivy implementiert, das seit 2006 ein Apache-Projekt und inzwischen ein Subprojekt von Ant ist.

Wir haben also auf der einen Seite das Werkzeug Ant (zusammen mit Ivy), das sehr große Freiheit, aber keine Unterstützung des Prozesses bietet und eine imperative Beschreibung aller Schritte erfordert.

Auf der anderen Seite haben wir Maven, das einen Prozess definiert und deklarative Beschreibung der Schritte durch eine Menge von Konventionen erlaubt. Dies wird allerdings dadurch erkauft, dass Maven sehr rigide Vorgaben macht, die das Build-Management früher oder später sehr problematisch machen.

Gradle

Gradle ist eine Antwort auf die Schwächen von Ant und Maven.

Eigentlich würden wir uns für das Build-Management ein Werkzeug wünschen, das die Funktionalität von Maven und den deklarativen Ansatz mit der Freiheit von Ant verbindet. Und genau dies tut Gradle.

Gradle bietet einen deklarativen Ansatz mit vernünftigen Konventionen, die leicht zu ändern sind, und durch die Integration von Ivy und Maven-Repositories exzellente Verwaltung der Abhängigkeiten und betrachtet Ant als einen gleichwertigen Partner, der voll integriert ist.

De facto ist jede Build-Datei für Gradle ein Groovy-Skript, das mit den Gradle-spezifischen Befehlen angereichert ist. Dies erlaubt prinzipiell die volle Programmierbarkeit des Build-Skriptes. Dies birgt natürlich die Gefahr, dass das Build-Skript, das eigentlich nur den Build beschreiben soll, durch zu viel Quelltext an Lesbarkeit verliert.

Deshalb sollten größere Teile Quelltext grundsätzlich in Plug-ins ausgelagert werden. Dies wir dadurch unterstützt, dass Plug-ins in Gradle sehr einfach zu schreiben und zu verwenden sind.

1.1 Grundsätzliche Aufgaben eines Build-Management-Werkzeugs

Historisch gesehen war die Aufgabe eines Build-Management-Werkzeugs sehr einfach, nämlich die Übersetzung von Quelltexten in der richtigen Reihenfolge und der darauf folgende Aufruf des Linkers, um ein ausführbares Programm oder eine Bibliothek zu erzeugen.

Funktionalitäten eines modernen Build-...