Ein neuer Stern am Himmel der Buildsysteme - JAXenter
buildr: Java-Projekte mit Ruby gebaut

Ein neuer Stern am Himmel der Buildsysteme

Markus Stäuble

Dynamische Skriptsprachen haben die Java-Welt in letzter Zeit sehr aufgemischt. Dieser Trend macht auch vor dem Erzeugen von Java-Projekten nicht halt. So hat die Apache Software Foundation (ASF) als ihr erstes Ruby-Projekt ausgerechnet ein Buildsystem herausgebracht. Der Name des Systems kann treffender nicht sein: buildr. Der Markt an Buildsystemen für Java, welcher hauptsächlich von ANT und Maven 2 geprägt wird, ist sehr groß. Die hochinteressante Verbindung der ASF und Ruby lassen dieses Projekt verführerisch wirken und rufen nach einem Test.

Eine wichtige Komponente innerhalb eines gut strukturierten Softwareentwicklungsprozesses ist ein funktionierender Buildprozess und somit auch das dafür eingesetzte Buildsystem. In der täglichen Softwareentwicklung ist es vor allem wichtig, sich auf die Entwicklung der Anforderungen konzentrieren zu können und nicht mit Infrastrukturkomponenten wie dem besagten Buildprozess beschäftigt zu sein. Somit ist die Hauptanforderung an solch ein System die Einfachheit und zugleich die Möglichkeit, alle Anforderungen an den Buildprozess damit abwickeln zu können. Aus diesem Grund muss das Release von buildr (basierend auf Rake – Ruby Make) sicherlich kritisch beäugt werden. Aber dies wurde auch Maven 2, als es von Apache als inoffizieller Nachfolger von ANT vorgestellt wurde. Viele Open-Source-Projekte wurden seitdem auf Maven 2 umgestellt.

buildr ist auf der einen Seite nicht das erste auf Ruby basierende Buildsystem, mit dem Java-Projekte gebaut werden können. Auch Raven ist ein mit Ruby (basierend auf Rake und RubyGems) getriebenes Buildsystem für Java-Projekte. Einer der größten Unterschiede zwischen Raven und buildr ist, dass buildr nicht direkt die Syntax von Rake verwendet, sondern eine eigene DSL (Domain Specific Language) mitbringt. Diese DSL erlaubt es auch für Neulinge in Ruby/Rake, sich sehr schnell mit buildr anzufreunden. Auch die Tatsache, dass ein erstes Toplevel Projekt von Apache (Apache Ode) von Maven 2 auf buildr umgestellt wurde, macht dieses Buildsystem mehr als interessant.

Definition der Spielregeln

Für die Bewertung der Fähigkeiten von buildr soll ein einfaches Demoprojekt verwendet werden, an dessen Buildprozess einige Anforderungen gestellt werden, die im Projektalltag in dieser oder ähnlicher Form eigentlich in jedem Java-Projekt auftauchen. Das Demoprojekt mit dem Namen testapplication besteht aus den nachfolgenden Teilen (Abb. 1):

  • core (API des Projekts wird sowohl von webclient als auch richclient verwendet)
  • webclient (Webclient mit Verwendung der Servlet API)
  • richclient (Richclient ohne besondere Abhängigkeiten)

Abb. 1: Projektstruktur des Demoprojekts

Die Anforderungen, die durch das Demoprojekt an das Buildsystem buildr gestellt werden, sind in Tabelle 1 aufgeführt.

Tabelle 1: Anforderungen aus dem Demoprojekt an buildr
Anforderung Beschreibung
Einbindung von 3rd-Party-Bibliotheken (Dependency Management) core verwendet Commons Lang in der Version 2.1.
Erzeugung von Jar-Dateien core und richclient
Erzeugung einer War-Datei webclient; Besonderheit an dieser Stelle ist, dass die verwendete Servlet-API nicht mit ins War-Archiv gepackt wird.
Automatische Ausführung von Unittests core, webclient
Verwendung von bestimmten Bibliotheken nur für Tests Webclient verwendet Spring-Mock
Kleines Starterkit

Als kleine Starthilfe soll zunächst die Installation unter Windows und danach die von buildr bereitgestellten Standardtasks erläutert werden.

Installation

Der erste Schritt in der Installation ist zunächst einmal Ruby. Hierfür kann der „One-Click Installer for Windows“ herangezogen werden. Nach dieser Installation fehlt nun noch buildr. Dies wird über RubyGems installiert. Dafür am besten in das bin Verzeichnis der Ruby Installation wechseln und folgendes Kommando absetzen: gem install buildr. Nun werden noch die notwendigen Pakete installiert und buildr ist einsatzfähig.

Standardtasks
Tabelle 2: Die Standardtasks von buildr
Name des Tasks Beschreibung
artifacts Lädt alle im buildfile definierten Abhängigkeiten in das lokale Repository (buildr verwendet Maven 2 Repositories). Dies ist vor allem sinnvoll, wenn man beabsichtigt, mit dem Projekt offline zu arbeiten.
build Baut das Projekt. Standardtask, der gestartet wird, wenn buildr ohne Angabe eines Tasks aufgerufen wird. Dieser Task ruft zunächst compile (und die zugehörigen Tasks wie ressources) auf und danach test (und die zugehörigen Tasks).
clean Löscht alle Dateien, die während eines Builds erzeugt wurden (gewöhnlich alle Dateien im Verzeichnis target)
compile Erzeugt alle Projekte
default Aufruf des Standardtasks (build)
eclipse Erzeugt die notwendigen Projektdateien für Eclipse (.classpath und .project) für die definierten Projekte
help:projects Ausgabe aller Projekte, die durch das Buildfile definiert werden
help:tasks Ausgabe aller Tasks, die durch das Buildfile definiert werden (inklusive der bereits durch buildr selbst definierten Tasks)
idea Erzeugt die notwendigen Projektdateien für IntelliJ IDEA für die definierten Projekte
install Installiert die erzeugten Artifakte im lokalen Repository
javadoc Erzeugt die Javadoc für die Projekte
junit:report Erzeugt die JUnit Reports im Verzeichnis reports/junit
package Erzeugt die definierten Packages
release Erzeugt das Release und installiert die erzeugten Artefakte in dem definierten Releaseserver
test Startet alle Tests
uninstall Entfernt die installierten Artefakte aus dem lokalen Repository
upload Lädt die erzeugten Artefakte auf den definierten Releaseserver

Hinweis: Die Tasks von buildr sind rekursiv, d.h. ein aufgerufener Task ist immer gültig für alle Projekte (Verzeichnisse), die sich unterhalb des Verzeichnisses befinden, in dem der Task aufgerufen wurde./ Kleines Starterkit

Geschrieben von
Markus Stäuble
Kommentare

Schreibe einen Kommentar

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