Ein neuer Stern am Himmel der Buildsysteme

buildr: Viel Glück

Das eben beschriebene Projekt, welches ohne Probleme in Eclipse gebaut werden kann, soll nun um einen durch buildr getriebenen Buildprozess erweitert werden. Der erste Schritt dafür ist der Aufruf von buildr im Hauptverzeichnis des Projektes. Da sich hier noch kein Buildfile befindet, wartet buildr mit der Frage auf, ob ein solches erzeugt werden soll. Das Buildfile wird dabei anhand der Verzeichnisstruktur (jedes Verzeichnis ist ein Subprojekt) erzeugt. Das für das Testprojekt erzeugte Buildskript ist in Listing 1 aufgeführt.

Listing 1
# Generated by Buildr 1.2.10, change to your liking
# Version number for this release
VERSION_NUMBER = "1.0.0"
# Version number for the next release
NEXT_VERSION = "1.0.1"
# Group identifier for your projects
GROUP = "testapplication"
COPYRIGHT = ""

# Specify Maven 2.0 remote repositories here, like this:
repositories.remote 

Bei jedem nun nachfolgenden Aufruf von buildr im Hauptverzeichnis des Projekts wird nun das soeben erzeugte Buildfile verwendet. Der Buildprozess scheitert nun daran, dass im Testprojekt ein Commons Lang in der Version 2.1 verwendet wird. Für diesen Zweck ist die erste Aufgabe an das neue Buildsystem, das Dependencymanagement abzuwickeln. Hierfür wird eine neue Variable definiert:

COMMONS_LANG = "commons-lang:commons-lang:jar:2.1"

Diese wird nun für das Kompilieren verwendet:

compile.with COMMONS_LANG

Weitere Bibliotheken können einfach mittels Komma getrennt angehängt werden. Die Projekte richclient und webclient verwenden die API aus core. Somit muss aus diesen Projekten auf das core Projekt verwiesen werden. Dies ist über project(„core“) möglich. Die Angabe, ob z.B. ein jar oder war erzeugt werden soll, erfolgt über package(:jar) oder package(:war). Für den webclient wird während der Kompilierung und der Tests die Servlet API benötigt, die allerdings aber nicht mit ins war-Archiv soll. Standardmäßig werden alle während des Kompilierungsvorgangs angegebenen Bibliotheken ins Archiv gepackt, das aber überschrieben werden kann.

package(:war).libs = COMMONS_LANG
package(:war).libs += projects("core")

Für den Test des Projekts webclient wird unter anderem auch Spring-Mock eingesetzt. Der Klassenpfad für die Tests kann folgendermaßen überschrieben werden:

test.with projects("core"), SERVLET_API, SPRING_MOCK,COMMONS_LANG

Die Ausführung von Tests erfolgt in buildr, sobald ein Test innerhalb von src/test/java vorhanden ist. Das nun fertige Buildskript ist in Listing 2 abgebildet.

Listing 2
# Generated by Buildr 1.2.10, change to your liking
# Version number for this release
VERSION_NUMBER = "1.0.0"
# Version number for the next release
NEXT_VERSION = "1.0.1"
# Group identifier for your projects
GROUP = "testapplication"
COPYRIGHT = ""


COMMONS_LANG = "commons-lang:commons-lang:jar:2.1"
SERVLET_API = "javax.servlet:servlet-api:jar:2.5"
SPRING_MOCK = group("spring-core", "spring-mock", :under=>"org.springframework", :version=>"2.0.6"), "commons-logging:commons-logging-api:jar:1.1"

# Specify Maven 2.0 remote repositories here, like this:
repositories.remote 

Das Buildskript kann einerseits im Hauptverzeichnis des Projekts ausgeführt werden und wird dann rekursiv für alle Projekte ausgeführt. Andererseits kann es auch in einem Unterverzeichnis (z.B. webclient) ausgeführt werden, in diesem Fall wird der Task nur für das Unterprojekt ausgeführt. Schön an dieser Lösung ist, dass die Unterprojekte kein eigenständiges Buildskript benötigen.