Macht der Wechsel alles besser?

Buildsysteme im Vergleich: Gradle

Der dritte Kandidat Gradle in diesem Vergleich ist auch der drittplatzierte in der Umfrage von JAXenter.

Wie bei den anderen beiden vorgestellten Systemen ist für die Installation von Gradle auch nur der Download eines Archivs (Name: gradle-0.8-all.zip) von der Webseite notwendig. Nach dem Entpacken (entpackte Distribution siehe Abb. 6) kann Gradle über das Kommandozeilenskript gradle (Verzeichnis bin in der Distribution) ausgeführt werden. Die Standarddistribution von Gradle setzt Java 1.5 voraus. Für den ersten Test der Installation kann über den Befehl gradle -version die Version des eingesetzten Gradle ausgegeben werden.

Abb. 6: Entpackte Distribution von Gradle 0.8

Für die Beschreibung des Builds kommt Gradle mit einer Groovy DSL (Domain Specific Language). In Gradle können Ant Tasks direkt verwendet werden, es basiert auf den Konventionen von Maven. Als Dependency Management kommt das schon erwähnte Ivy zum Einsatz.

Der Standardname des Build-Skripts lautet build.gradle. Um ein Projekt in Maven-Struktur zu bauen, muss lediglich die Anweisung usePlugin ‚java‘ angegeben werden. Da für das Dependency Management Ivy eingesetzt wird, kann auf Maven-Repositories zugegriffen werden. Im Block dependencies werden hierfür die Abhängigkeiten beschrieben werden. Nachfolgendes Listing zeigt ein Build-Skripts mit dem das Projekt core übersetzt werden kann. Über gradle compileJava werden die Quelldateien übersetzt. Die Ausführungseinheit bei Gradle heißt (wie bei Ant auch) Task. Über den Aufruf gradle -t können alle verfügbaren Tasks ausgegeben werden:

usePlugin 'java'

sourceCompatibility = 1.5
version = '1.0.0'

repositories {
mavenCentral()
}

dependencies {
compile group: 'commons-lang', name: 'commons-lang', version: '2.4'
}

Für die Ausführung der Tests muss der Block dependencies um JUnit erweitert werden. Bei Gradle werden die Abhängigkeiten in Gruppen eingeteilt, vergleichbar mit dem Element scope bei Maven. Nach der Ergänzung der Abhängigkeit können die Tests über gradle test ausgeführt werden:

dependencies {
compile group: 'commons-lang', name: 'commons-lang', version: '2.4'
testCompile group: 'junit', name: 'junit', version: '4.+'
}

Um das Archiv zu erzeugen, ist der Befehl gradle assemble oder gradle jar abzusetzen. Das Archiv und auch die erzeugten Klassen befinden sich bei Gradle im Verzeichnis build. Die Manifest-Datei kann über den Block manifest angepasst werden:

manifest.mainAttributes(
'Implementation-Version': version
)

Beim eingesetzten Testprojekt handelt es sich um ein Projekt mit mehreren Modulen. Für die Projekte richclient und webclient wird das gebaute Projekt core vorausgesetzt. Dies muss somit über die Abhängigkeiten referenziert werden können. Über project(‚:core‘) kann direkt auf das Projekt zugegriffen werden. Um das war-Archiv zu erzeugen, wird das war-Plug-in verwendet. Im nachfolgenden Listing ist das Build-Skript abgebildet:

usePlugin 'war'

sourceCompatibility = 1.5
version = '1.0.0'

repositories {
mavenCentral()
}

dependencies {
compile 'javax.servlet:servlet-api:2.5', project(':core')
}

Bei der Ausführung des Skripts im Verzeichnis webclient wird ein Fehler ausgegeben, denn das Projekt core ist für webclient nicht bekannt. Hierfür ist eine Einstellungsdatei mit dem Namensettings.gradle im Hauptverzeichnis des Projekts notwendig. In dieser Datei werden die Subprojekte deklariert: include „core“, „richclient“, „webclient“. Der Build wird nun nicht mehr im Unterverzeichnis, sondern im Hauptverzeichnis aufgerufen. Um das war-Archiv zu erzeugen, muss das Kommando gradle :webclient:war ausgeführt werden. Ohne Angabe eines Unterprojektes wird der angegebene Task auf allen Projekten ausgeführt. Zur Ausführung von Checkstyle (Anforderung 6) ist ein zusätzliches Plug-in einzubinden. Außerdem ist der Pfad zur Konfiguration von Checkstyle notwendig. Nachfolgendes Listing zeigt die zwei Zeilen, die dem Build-Skript hinzugefügt werden müssen:

usePlugin 'code-quality'
checkstyleConfigFileName = 'sun_checks.xml'

Über den Aufruf gradle :core:checkstyleMain wird Checkstyle auf den Quellen des Projekts core ausgeführt.

Welches Build-System ist nun das richtige?

Dieser Artikel hat die derzeit drei verbreitesten Build-Systeme im Java-Bereich vorgestellt. Bei weitem sind das aber nicht alle verfügbaren Systeme. Vor allem Wechsler von Ant zu Maven fragen sich anfangs, ob das wirklich Besserung gebracht hat. Ob mit Maven alles besser oder schlechter ist, sei dahingestellt, was aber Maven geschafft hat, ist eine Standardisierung im Bereich von Java-Projekten. Damit ist es möglich, schnell in andere Java-Projekte einzutauchen, denn wenigstens findet man schnell die richtigen Ablageorte. Auch Gradle verwendet diesen Standard. Trotzdem geht Gradle eher den Weg von Ant als von Maven. Der Entwickler hat die Möglichkeit, schnell im Skript einen kleinen Task zu programmieren. Eine Eigenschaft, die in wachsenden Projekten doch hin und wieder benötigt wird und mit Maven nicht so einfach machbar ist.

Bei der Wahl des Build-Systems sollte man sich zunächst den eigenen Anforderungen bewusst werden und danach prüfen, mit welchem System am einfachsten ein verständlicher und wartbarer Build möglich ist. Mit den drei vorgestellten Systemen ist sehr viel möglich. Der Aufwand ist aber auch bei allen drei Systemen unterschiedlich. Letztendlich bleibt das Build-System aber nur Hilfsmittel, und der Kunde bezahlt für die fertige Software und nicht den ausgefeilten Build. Somit bleibt am Schluss der Rat: Setzen Sie auf Standard und schaffen Sie sich nicht einen eigenen Build-Komplex.

Markus Stäuble ist Senior IT-Consultant bei der MRM Worldwide GmbH. Er schreibt regelmäßig Artikel für diverse Fachzeitschriften und gibt sein Wissen gerne in Vorträgen wieder.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.