Gradle
| Gradle
| |
|---|---|
| |
| Basisdaten
| |
| Hauptentwickler | Gradle Inc. |
| Entwickler | Gradle Inc., Adam Murdoch[1], Daz DeBoer[2], Bo Zhang[2] |
| Erscheinungsjahr | 2008[3] |
| Aktuelle Version | 8.10.2[4] (23. September 2024) |
| Betriebssystem | Plattformunabhängig |
| Programmiersprache | Java, Groovy[5], Kotlin |
| Kategorie | Build-Management-Tool |
| Lizenz | Apache-Lizenz, Version 2.0[6] |
| gradle.org | |
Gradle ist ein auf Java basierendes Build-Management-Automatisierungs-Tool, vergleichbar mit Apache Ant und Apache Maven. Gradle nutzt 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 inkrementelle als auch parallel ablaufende Build-Prozesse. Erstere ermöglichen es, dass nur die Teile einer Software gebaut werden, die 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.[7] Seit Mitte 2013 hinzugekommen ist das Android-System. Seitdem wird das Tool vor allem zur Unterstützung zum Bau sogenannter „nativer“ Systeme ausgebaut, welche nicht auf der Java-Plattform basieren. Unterstützt werden hier die Programmiersprachen C++, C, Objective-C und Assembler.
Konzeption und Plugin-Architektur
[Bearbeiten | Quelltext bearbeiten]Gradles Build-Konzept übernimmt die von Maven eingeführten Standardkonventionen („convention over configuration“) für das Verzeichnislayout der Projektquellen sowie die üblichen Phasen für den Bau eines (Java-)Projekts (Validieren, Kompilieren, Testausführung, Archiv-Erstellung und Report-Generierung, 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, Unternehmens- 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-Projekten 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, es 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
[Bearbeiten | Quelltext bearbeiten]Im Gegensatz zu den Konventionen von Apache Maven und dessen XML-Deklarationen arbeitet der Anwender mit Gradles Domänenspezifischer Sprache (domain-specific language, kurz DSL), 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.
Seit Gradle 5.0 wird zusätzlich eine Kotlin DSL als Alternative zur Groovy DSL angeboten; diese erlaubt insbesondere eine verbesserte Autovervollständigung in den Entwicklungsumgebungen.[8][9]
Der Gradle-Build
[Bearbeiten | Quelltext bearbeiten]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 die Task ‚test‘ nur ausgeführt, wenn zuvor die Tasks ‚compile‘, ‚process-resources‘, ‚classes‘, ‚testCompile‘ ohne Fehler durchlaufen wurden.
Build-Dateien
[Bearbeiten | Quelltext bearbeiten]Gradle nutzt für einen einfachen Build hauptsächlich 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“
[Bearbeiten | Quelltext bearbeiten]Das einfachste Buildskript für ein Java-Projekt sieht so aus:[10]
apply plugin: 'java'
Beispiel für die Definition einer eigenen Task:
task hello << {
println 'Dies ist der Hello-Task'
}
Eine Task kann über die Kommandozeile aufgerufen werden:
$ gradle hello
IDE-Unterstützung
[Bearbeiten | Quelltext bearbeiten]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
[Bearbeiten | Quelltext bearbeiten]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-Repositories von Gradle unterstützt. Mittels des Build Init Plugin können Maven-Projekte nach Gradle konvertiert werden.[11]
Literatur
[Bearbeiten | Quelltext bearbeiten]- Tim Berglund, Matthew [J.] McCullough: Building and Testing with Gradle. O’Reilly Media, Sebastopol CA 2011, ISBN 978-1-4493-0463-8.
- Joachim Baumann: Gradle: Ein kompakter Einstieg in das Build-Management-System. d.punkt.verlag, 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. Packt Publishing, 2012, 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
[Bearbeiten | Quelltext bearbeiten]Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ github.com.
- ↑ a b github.com.
- ↑ gradle.com.
- ↑ github.com.
- ↑ The gradle Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 18. Juli 2018).
- ↑ The gradle Open Source Project on Open Hub: Licenses Page. In: Open Hub. (abgerufen am 18. Juli 2018).
- ↑ Gradle Homepage
- ↑ heise online: Gradle 5.0 unterstützt Java 11. 3. Dezember 2018, abgerufen am 24. Juni 2021.
- ↑ Gradle Kotlin DSL Primer. In: Gradle User Manual. Abgerufen am 24. Juni 2021.
- ↑ The Java Plugin. In: Gradle User Manual. Abgerufen am 24. Juni 2021.
- ↑ Build Init Plugin. In: Gradle User Manual. Abgerufen am 24. Juni 2021.