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.
Hinterlasse einen Kommentar