Gradle

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.

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]

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.

apply plugin: 'java'

task hello << {
    println 'Dies ist der Hello-Task'
}

$ gradle hello

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.

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]

• 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

• Website des Projekts
  • Dokumentation

1. github.com.
2. github.com.
3. gradle.com.
4. github.com.
5. The gradle Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 18. Juli 2018).
6. The gradle Open Source Project on Open Hub: Licenses Page. In: Open Hub. (abgerufen am 18. Juli 2018).
7. Gradle Homepage
8. heise online: Gradle 5.0 unterstützt Java 11. 3. Dezember 2018, abgerufen am 24. Juni 2021.
9. Gradle Kotlin DSL Primer. In: Gradle User Manual. Abgerufen am 24. Juni 2021.
10. The Java Plugin. In: Gradle User Manual. Abgerufen am 24. Juni 2021.
11. Build Init Plugin. In: Gradle User Manual. Abgerufen am 24. Juni 2021.