Und nun zu etwas völlig anderem: Build automation mit Gradle. Richtig, ein technischer Beitrag 
Gradle ist ein sehr interessates und mächtiges Buildsystem, dass nicht wie Ant auf XML zur Konfiguration setzt, sondern Groovy als DSL (Domain Specific Language) einsetzt um zum Ziel zu kommen. Dadurch wird es sehr mächtig und vielseitig einsetzbar. Das interessante ist auch, das Groovy sanfte Migrationen, zum Beispiel von Maven oder Ant ermöglicht, indem man vorhandene Konfigurationen von dort einfach einbinden und weiterverwenden kann.
Leider hat Gradle zur Zeit leider noch die Schwäche hat, nicht besonders umfangreich dokumentiert zu sein. Auch in den Weiten des Netz hat es noch nicht genug Spuren hinterlassen, als dass jede Frage schnell mit Google beantwortet werden kann. Und genau das hat mich zu diesem Beitrag inspiriert, in dem ich kurz ein Beispiel für ein Gradle Skript festhalten möchte, der einige Anpassungen für die Erstellung der Dokumentation mit JavaDoc enthält:
build.gradle:
apply plugin: 'java'
dependencies {
compile fileTree(dir: libDir, include: '*.jar')
}
javadoc {
appName = 'my application'
developerEmail = test@domain.com
project.configure(options) {
memberLevel = org.gradle.external.javadoc.JavadocMemberLevel.PROTECTED
charSet = "ISO-8859-1"
docTitle = "$appName"
windowTitle = "$appName"
header = "$appName"
bottom = "Contact via " + developerEmail.trim() +" $developerName for feedback."
author = "true"
use = "true"
links("http://java.sun.com/j2ee/1.4/docs/api", "http://java.sun.com/j2se/1.5.0/docs/api")
}
}
task initDirs
In der definierten Fusszeile (bottom) oder auch im initDirs-Task kann man gut die Stärke von Groovy als DSL erkennen.
Gradle verfügt über eine Menge interessanter Features, einen Blick darauf zu werfen kann ich durchaus empfehlen ![:)]()
Auf dem ersten Hackergarten im März haben wir auch daran mitgearbeitet. Erfreulicher weise wurden unsere Änderungen angenommen und sind nun in Gradle enthalten - Open Source live!
