Gradle
Gradle | |
---|---|
Logo von Gradle | |
Basisdaten | |
Hauptentwickler | Hans Dockter, Adam Murdoch, Szczepan Faber, Peter Niederwieser, Daz Deboer, Luke Daley, Rene Groeschke |
Entwickler | Gradle Inc., Adam Murdoch[1] , Daz DeBoer[2] , Bo Zhang[2] |
Erscheinungsjahr | 2008[3] |
Aktuelle Version | 2.4[4] (5. Mai 2015) |
Aktuelle Vorabversion | 5.6 RC1[5] (29. Juli 2019) |
Betriebssystem | plattformübergreifend |
Programmiersprache | Java, Groovy |
Kategorie | Build-Management-Tool |
Lizenz | Apache-Lizenz 2.0 |
www.gradle.org |
Gradle ist ein auf Java basierendes Build-Management-Automatisierungs-Tool, vergleichbar mit Apache Ant und Apache Maven. Gradle nutzt dabei eine auf Groovy basierende domänenspezifische Sprache (DSL) zur Beschreibung der zu bauenden Projekte. Im Gegensatz zu Maven-Projektdefinitionen (pom.xml) sind Gradle-Skripte direkt ausführbarer Code.
Gradle wurde für Builds von Softwaresystemen entworfen, welche aus einer Vielzahl von Projekten bestehen. Basierend auf der Philosophie „Erwarte das Unerwartete" wurde versucht, das in Maven etablierte „build-by-convention"-Prinzip (eine Variante von „Konvention vor Konfiguration") mit der Flexibilität von Ant zusammenzubringen.
Builds umfangreicher Projekte können sehr viel Zeit in Anspruch nehmen. Darum unterstützt Gradle sowohl inkrementelles als auch Bauen der Software durch parallel ablaufende Build-Prozesse. Ersteres ermöglicht es, dass nur die Teile einer Software gebaut werden, welche verändert wurden oder auf veränderten Teilen beruhen, zweiteres ermöglicht es, dass bestimmte Tasks beim Build (beispielsweise die Tests) parallel auf mehreren CPUs oder Rechnern laufen. Damit lässt sich eine wesentlich höhere Geschwindigkeit des Erstellprozesses erreichen.
Gradle wird von einigen bekannten Frameworks für deren Build eingesetzt – darunter Hibernate, Grails, Groovy sowie Spring Integration und Spring Security.[6] Seit Mitte 2013 hinzugekommen ist das Android-System. Seitdem wird das Tool vor allem ausgebaut zur Unterstützung zum Bau sogenannter „nativer" Systeme, welche nicht auf der Java-Plattform basieren. Unterstützt werden hier die Programmiersprachen C++, C, Objective C und Assembler.
Konzeption und Plugin-Architektur
Gradles Build-Konzept übernimmt die von Maven eingeführten Standardkonventionen („convention over configuration") für das Verzeichnislayout der Projektquellen, die üblichen Phasen für den Bau eines (Java-) Projekts (Validieren, Kompilieren, Testausführung, Archive-Erstellung und Report-Generierung erstellen, Verteilung). Die Build-Datei kann daher minimal ausfallen und bei einem simplen Java-Projekt aus einer einzigen Zeile („apply plugin: 'java'
") bestehen. Ebenso übernimmt Gradle weitgehend das Maven-Konzept des Managements der Abhängigkeiten eines Projekts von anderen Projekten oder Fremdbibliotheken. Gradle kann sich hierbei auf die weitverbreiteten Maven Repositories (lokale, Firmen- und Internet-Repositories) stützen. Alternativ kann der Anwender aber auch auf Ivy-Repositories zurückgreifen.
Ähnlich wie Maven besteht Gradle aus einem abstrakten Kern und einer Vielzahl von Plug-ins und ist durch diese Struktur vielfältig erweiterbar. Selbst die Implementierung des Java-Builds basiert auf einem Plugin für Java. Mit dieser Architektur bietet Gradle die Möglichkeit, Buildprozesse für beliebige Software-Plattformen bewerkstelligen zu können und liefert dem Anwender die Möglichkeit, seine „nicht-konventionellen" Vorstellungen dem Tool beizubringen. Gradle liefert von Hause aus Plug-ins mit, die neben Java Groovy-, Scala- und C++- Projekte bauen können. Daneben wird der Build von Java Enterprise Archiven (WAR, EAR) unterstützt. Weitere Plug-ins erlauben die Überwachung der Softwarequalität (beispielsweise FindBugs, PMD, Checkstyle) durch automatisierte Checks und Generierung entsprechender Reports.
Die mit Gradle mitgelieferten Plug-ins sind zwar hauptsächlich für die Entwicklung und das Deployment von Java-, Groovy- und Scala-Projekten gemacht. Gradle kann aber auch für andere Programmiersprachen und Workflows eingesetzt werden. Seit der Entscheidung des Android-Teams für Gradle als Build-System wird von den Entwicklern hauptsächlich die Unterstützung eines Buildmodells für native Programmierumgebungen vorangetrieben.
Gradle DSL
Im Gegensatz zu den Konventionen von Apache Maven und dessen XML-Deklarationen arbeitet der Anwender mit Gradles Domänenspezifischer Sprache, die er – da eine Gradle-Build-Datei immer ein Groovy-Skript darstellt – erweitern oder in den Standardeigenschaften ändern kann. Ebenso kann er mit Groovy-Code eigene Build-Änderungen schreiben oder vordefinierte Standards überschreiben und eigenen Belangen anpassen. Der Gradle-Anwender kann beide Stile verwenden: den deklarativen, auf Standardkonventionen beruhenden Ansatz von Maven und den eher imperativen Ansatz von Ant, bei dem der Anwender aber auch alles im Detail definieren muss.
Der Anwender ist auf Basis dieser DSL-Sprache nicht gezwungen, zuerst einmal Groovy lernen zu müssen, bevor er sich an Gradle-Buildskripte heranwagt.
Der Gradle-Build
Gradle kennt zwei Hauptphasen der Buildverarbeitung, die immer durchlaufen werden: Konfiguration und Ausführung. Während des Konfigurations-Zyklus wird die gesamte Build-Definition durchlaufen, um den Abhängigkeitsgraphen (DAG) zu erzeugen, der die Reihenfolge aller abzuarbeitenden Schritte enthält. Im zweiten Teil wird dieser Graph für die gewünschten Tasks durchlaufen. Sowohl die Konfiguration als auch die Ausführung sind dem Anwender durch eine offene API zugänglich.
Der Buildprozess, der durch den Task-Graphen beschrieben wird, besteht aus einer Abfolge von Tasks, die hierarchisch voneinander abhängen, und wo ein Nachfolger nur ausgeführt wird, wenn seine Vorgänger erfolgreich durchlaufen wurden. So wird beispielsweise der Task ‚test‘ nur ausgeführt, wenn zuvor die Tasks ‚compile‘, ‚process-resources‘, ‚classes‘, ‚testCompile‘ ohne Fehler durchlaufen wurden.
Build-Dateien
Gradle nutzt für einen einfachen Build hauptsächliche drei benutzerdefinierte Dateien:
- build.gradle – die auf der Gradle-DSL beruhende Definition des Builds mit allen Tasks und Abhängigkeiten eines Projekts (ein Multiprojekt hat pro Projekt eine solche Build-Datei, die durch Vererbung der Eigenschaften von ihrem „Vater"-Buildskript kurz gehalten werden können).
- settings.gradle (optional) – bei einem Multiprojekt werden hier die teilnehmenden Unterprojekte festgelegt.
- gradle.properties (optional) – eine Liste von Properties, die für die projektspezifische Gradle-Initialisierung eines Builds gültig sind.
Gradle-Skripte können unmittelbar Groovy-Code enthalten oder durch eine Groovy-Klasse implementiert werden. Alternativ lassen sie sich als Build-Abhängigkeit aus einem Maven-Repository laden.
Einfache Beispiele für die Datei „build.gradle"
Das einfachste Buildskript für ein Java-Projekt sieht so aus:
applyplugin:'java'
Beispiel für die Definition eines eigenen Tasks:
taskhello<<{ println'Dies ist der Hello-Task' }
Ein Task kann über die Kommandozeile aufgerufen werden:
$gradlehello
oder interaktiv über eine eingebaute Oberfläche
$gradle--gui
Dokumentation
Die Gradle Dokumentation (Tutorial, Handbuch, API-Dokumentation) soll den Einsteiger schnell in den Umgang mit Gradle einführen. Die Dokumentation ist über die Gradle-Website online zugänglich und liegt dem Download-Paket bei.
IDE-Unterstützung
Für viele Integrierte Entwicklungsumgebungen gibt es Gradle-Plug-ins, darunter NetBeans, IntelliJ IDEA und Eclipse. Alternativ können über Gradle-Plug-ins Eclipse- und IDEA-Projektdateien erzeugt werden.
Weitere Details
Apache-Ant-Builds können von Gradle abgelöst werden, indem die build.xml-Dateien nach Gradle importiert werden. Auch können Ant-Tasks direkt aus der DSL aufgerufen werden. Ebenso kann Gradle Artefakte in Apache-Maven-Repositories sowohl als Abhängigkeiten konsumieren als auch Artefakte dort publizieren. Weiterhin werden Apache-Ivy-Repositorys von Gradle unterstützt. Mittels des in Entwicklung befindlichen Build Init Plugin sollen Maven-Projekte nach Gradle konvertiert werden können.[7]
Literatur
- Tim Berglund, Matthew [J.] McCullough: Building and testing with Gradle. O'Reilly Media, Sebastopol CA, USA 2011, ISBN 978-1-4493-0463-8.
- Joachim Baumann: Gradle: Ein kompakter Einstieg in das Build-Management-System. d.punkt.verlag GmbH, 2013, ISBN 978-3-86490-049-5.
- Benjamin Muschko: Gradle in Action. Manning Publications, 2014, ISBN 978-1-61729-130-2.
- Hubert Klein Ikkink, Gradle Effective Implementation Guide. (2012), Packt Publishing, ISBN 1-84951-810-6
- Etienne Studer: Ein Einstieg in Gradle für Java-Entwickler, Gradle wird den Build schon schaukeln und Enterprise Gradle, 3-Teilige Serie über Gradle im Java Magazin 1 bis 3/2011
Weblinks
Einzelnachweise
- ↑ github.com.
- ↑ a b github.com.
- ↑ gradle.com.
- ↑ Gradle Release Notes. 5. Mai 2015, abgerufen am 8. Mai 2015 (englisch).
- ↑ github.com.
- ↑ Gradle Homepage
- ↑ Build Init Plugin