Gradle
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 ( 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.[8] 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-ArchitekturGradles 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 ( Ä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 DSLIm 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.[9][10] Der Gradle-BuildGradle 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-DateienGradle nutzt für einen einfachen Build hauptsächlich drei benutzerdefinierte Dateien:
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:[11] 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ützungFü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 DetailsApache-Ant-Builds können von Gradle abgelöst werden, indem die Literatur
WeblinksEinzelnachweise
|