Gradle – ein Überblick


Motivation

Nach Make, Ant und Maven gibt es seit einiger Zeit ein weiteres Buildsystem der Open Source Gemeinde auf dem Markt. Ich habe mich gefragt ob dieses System nur entstanden ist weil es aktuell als modern gilt DSLs einzusetzen oder weil Skriptsprachen wie Groovy, welche von einer JVM (Java Virtual Machine) ausgeführt werden können, gerade einen Hype erleben. Möglicherweise gibt es ja auch andere Gründe. Zufällig durfte ich kürzlich einem Vortrag „Gradle wird den Build schon schaukeln“ gehalten vom Gradle Erfinder und Gründer der Firma Gradleware, Hans Dockter, beiwohnen. Zusätzlich habe die Artikel [Staeuble2010] und [Studer2011] gelesen.

Grundideen von Gradle

Gradle ist ein Buildsystem dessen Buildskripte auf einer objektorientierten DSL basieren. Diese Sprache ist über Plugins einfach um weitere Sprachelemente erweiterbar.

Gradle unterteilt einen Build in eine Konfigurations- und eine Ausführungsphase. Es wird von einem 2 Phasen Build gesprochen. Die Konfigurationsphase ist die erste Phase und kann beispielsweise auch zur Abfrage von Zugangsinformationen genutzt werden, welche später in der Ausführungsphase zum Zugriff auf Remote Ablagen verwendet werden können.

Gradle realisiert tatsächlich inkrementelle Builds. Es ist nicht mehr notwendig „zur Sicherheit vor dem Build ein clean“ auszuführen. Gradle bemerkt Veränderungen in den Quellen genauso wie in den gebildeten Artefakten. Dies gilt auch für eigene Skripterweiterungen wenn diese als Plugins ausgelagert werden.

Gradle unterstützt eine Trennung zwischen deklarativen und imperativen Aspekten eines Builds. Die Buildskripte selbst sollten vorwiegend deklarative Elemente enthalten, da Gradle den Build idealerweise deklarativ beschreibt. Eigene Erweiterungen programmatischer Art (also keine Konfigurationen der Tasks oder Plugins) sind ebenfalls im imperativen Stil in den Buildskripten möglich. Diese Anpassungen sollten jedoch temporärer Natur sein und später in separate Dateien/Plugins ausgelagert werden. Die hierbei benutzte Programmiersprache ist Groovy. Die Aufteilung zwischen deklarativen und imperativen Aspekten wird zur Umsetzung des Konzeptes Separation of Concern benutzt (Trennung zwischen dem Was getan werden soll und dem Wie es getan werden soll). Die deklarativen Teile beschreiben hierbei was vom Build erledigt werden soll. Die imperativen Teile (Tasksimplementierungen und Plugins) beschreiben wie die einzelnen Aktionen zu realisieren sind.

Gradle unterstützt die bereits existierenden Buildsysteme ANT und Maven sowie das Dependency Managementsystem Ivy. Dadurch, dass sowohl auf Maven und Ivy Repositories zugegriffen werden kann, ANT Skripte integriert und Mavens pom.xml importiert und in ein Gradle Buildskript gewandelt werden kann, eignet sich Gradle hervorragend zum Einsatz in hybriden Buildumgebungen. Da ein Grundkonzept von Gradle darin besteht, sich an existierende Projektstrukturen anzupassen wird eine Migration bestehender ANT oder Maven gesteuerter Projekte zu Gradle hervorragend unterstützt.

Übersicht über die Eigenschaften des Build Systems

Eigenschaft Gradle
2 Phasen Build Konfiguration und Ausführungsphase
Inkrementelles Build Bemerkt veränderte Quellen wie auch Veränderungen an den gebildeten Artefakten
Multimodule Projekte Projekte mit Submodulen oder Subprojekten können problemlos in den Build integriert werden
Mehrere Zielartefakte
möglich?
Keine Beschränkung der Anzahl der zu bildenden Artefakte.
Sprache der Buildskripte Taskbasierte DSL auf Groovy Basis
Integration anderer Buildsysteme Buildsysteme ANT und Maven sind vollständig integriert. Ebenso die Abhängigkeitsverwaltung Ivy.
Zugriff auf Repositories Maven und Filesystem (Strukturen definierbar)
 Installation anderer Systeme notwendig  Weder Maven noch Ivy noch ANT müssen installiert sein. Selbst die korrekte Gradle Version kann über Wrapper Skript erst erstellt werden
 Revisionssicherheit  Alle Releases können mit exakt den selben Versionen der zum jeweiligen Zeitpunkt benutzten Artefakten (auch Gradle Version) später erneut gebildet werden
 Parallele Builds  in Vorbereitung

Quellennachweise

[Staeuble2010]
Stäuble, M. (2010), ‚Build-Systeme im Vergleich‘, Java Magazin 5 , 60 – 69 .
[Studer2011]
Studer, E. (2011), ‚Gradle wird den Build schon schaukeln.‘, Java Magazin (2) , 104 – 109 .
Post a comment or leave a trackback: Trackback URL.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: