Schöner schaukeln mit Gradle?

Die Konstruktion qualitativ hochwertiger Software setzt den Einsatz geeigneter Prozesse und Werkzeuge voraus. Von essentieller Bedeutung hinsichtlich der Qualität des Produkts ist der Build-Prozess: eine definierte Folge von Schritten die erforderlich sind, um aus einer Menge von Sourcecodedateien und sonstiger Ressourcen – sowie unter Berücksichtigung der Abhängigkeiten von Bibliotheken oder zwischen einzelnen Projektteilen – ein funktionierendes Ganzes zu bauen. Vereinfacht gesagt, denn dazu kommt noch die Ausführung einer Vielzahl von Unit- und Integrationstests (sowohl auf den Entwicklermaschinen als auch in Continuous Integration Umgebungen), das Erzeugen von Dokumentation, Releasemanagement, usw.
Schon bei Projekten mit überschaubarem Umfang müssen die Builds automatisiert werden (build automation). Dies ist der einzige Weg die richtige und fehlerfreie Abfolge der Schritte, welche den Build-Prozess ausmachen, zu gewährleisten. Build-Performance spielt dabei eine nicht unwesentliche Rolle. Agile Prozesse (wie z.B. Scrum) mit ihren kurzen Releasezyklen werden erst durch die Automatisierung von Build-Prozessen möglich. Wir setzen derzeit für die meisten Projekte das Build-Tool Maven ein.
Passend zum Thema build automation stellte Hans Dockter letzte Woche im Rahmen der regelmäßig stattfindenden Java User Group (JUG KA) Veranstaltung das Build-Tool Gradle vor: “Gradle wird den Build schon schaukeln” war der hoffnungsvoll klingende Titel des Vortrags. Hans Dockter ist Initiator des Gradle Projekts sowie CEO von Gradleware. In etwa zweieinhalb Stunden gab es Einblicke in die Konzepte und die Funktionsweise von Gradle, einige Anwendungsbeispiele, Antworten auf Fragen, Diskussionen sowie einen Ausblick auf geplante Features in zukünftigen Releases (derzeit sind lediglich Milestone-Releases veröffentlicht; aktueller Milestone-Release ist Gradle 1.0-milestone-5).
Daß der Gradle-Zug schon ordentlich Fahrt aufgenommen hat ist mittlerweile nicht mehr zu übersehen: Hibernate, Spring Security und Grails beispielsweise sind auf Gradle-basierte Builds umgestiegen. Stellt sich noch die Frage, ob es sich lohnt jetzt auf den Zug aufzuspringen und Gradle als Build-Tool einzusetzen. Das hängt natürlich vom jeweiligen Projekt und den Anforderungen an den Build ab; und bei existierenden Projekten sicher auch vom bisher eingesetzten Build-Tool. Einen funktionierenden Maven-basierten Build möchte man nicht ersetzen, oder doch?
Maven verfolgt einen deklarativen Ansatz: es wird definiert was in den einzelnen Phasen des Builds zu tun ist und nicht wie es zu tun ist. Vergleicht man diesen Ansatz mit dem imperativen Ansatz von Ant (dort wird für jeden Schritt beschrieben wie etwas zu tun ist), erkennt man schnell den Vorteil den Maven gegenüber Ant bietet: erhöhte Lesbarkeit und Wartbarkeit. Die Anforderungen an einen Build-Prozess ändern sich aber mit der Zeit. Erweiterbarkeit spielt dementsprechend eine wichtige Rolle. Und Flexibilität. Was Maven-Builds betrifft: Flexibilität ist hier leider ein Problem.
Auch Gradle ist ein deklaratives Build-System. Bei der Beschreibung des Build-Prozesses steht immer das Was – und nicht das Wie – im Vordergrund. Builds werden mit einer Groovy-DSL (Domain Specific Language) deklarativ beschrieben. Die DSL ist aber beliebig erweiterbar, d.h. daß im imperativen Stil neue Tasks definiert werden können, welche im Build-Script als deklarative Elemente verwendbar sind. Der imperative Aspekt garantiert hohe Flexibilität. Durch die Möglichkeit die DSL zu erweitern ist eine Trennung von imperativer Schicht und deklarativer Schicht gegeben.
Maven dagegen zwingt dem Build ein starres (Phasen-)Modell auf, was Maven-Builds unflexibel macht. Scheinbar einfache Anforderungen wie das Handling von Unit- und Integrationstests werden zu nervigen Angelegenheiten und sind oftmals nur umständlich zu erreichen. Darunter leidet dann wieder die Les- und Wartbarkeit. Andere Aufgaben lassen sich nur durch Anpassungen an Maven-Plugins oder durch Einbindung von Ant-Tasks umsetzen (zwar wird das Ausführen von Groovy Scripts unterstützt, aber ein Ausbrechen aus dem starren Phasenmodell von Maven ist auch damit nicht möglich).
Gradle integriert mit Build-Systemen wie Ant und Maven. Das macht Sinn, da die Build-Landschaft heterogen ist. So können sowohl Ivy- als auch Maven-Repositories genutzt werden. Die aktive und schnell wachsende Community wird die Integration mit anderen Tools (wie z.B. Entwicklungsumgebungen) weiter vorantreiben. Geplant ist ausserdem ein Portal für Open Source Gradle Plugins. Ideale Voraussetzungen also um den Start mit Gradle zu wagen. Der Einstieg ist nicht schwer: der Gradle User Guide ist hier ein guter Ausgangspunkt.
Gradle ist Open Source und steht unter der Apache Software License Version 2.0