Apache Buildr – Die Maven-Alternative?

Die Kernkonzepte

Projektstruktur: Anders als Maven werden Multi-Modul-Builds nicht auf mehrere POMs verteilt, sondern in einer einzigen Build-Datei namens buildfile beschrieben. Dabei können Unterprojekte beliebig häufig verschachtelt sein. Buildr geht zunächst davon aus, dass die einzelnen Projekte der Maven-Konvention, also src/main/java für Java-Code, src/main/resource für Ressourcen, src/test/java für Java-Tests, src/test/resources/ für Testressourcen etc. folgen. Es lassen sich aber auch andere Projektlayouts konfigurieren. Analog zu den GAV-Koordinaten der Maven-Projekte (Group, Artifact, Version) werden jedem Projekt eine artifactId, eine groupId und eine Version zugewiesen. Für jedes Projekt (und die Unterprojekte) definiert Buildr automatisch eine Reihe von Tasks, die den Lifecycles von Maven sehr nahe kommen:

  • clean: löscht alle während des Builds erzeugten Dateien
  • compile: kompiliert das Projekt und seine Unterprojekte
  • test: testet das Projekt und seine Unterprojekte
  • build: kompiliert und testet das Projekt und seine Unterprojekte
  • package: erzeugt JARs, WARs, EARs, AARs, Zips oder OSGi Bundles
  • install: kopiert die erzeugten Artefakte in das lokale Maven-Repository
  • upload: lädt die erzeugten Artefakte in ein entferntes Maven-Repository
  • eclipse/idea: erzeugt die Hilfsdateien, um die Projekte in Eclipse oder IDEA öffnen zu können
  • cc: wartet kontinuierlich auf Änderungen der Quelldateien und startet dann automatisch die Kompilierung
  • release: erzeugt ein Release mit Tag in der Versionskontrolle und lädt die Artefakte in ein Maven-Repository hoch
  • junit:report: erzeugt die HTML-Reports für die JUnit-Testfälle

Abbildung 2 zeigt die Abhängigkeiten der wichtigsten Tasks.

Abb. 2: Abhängigkeiten der wichtigsten globalen Tasks
Kommentare

Schreibe einen Kommentar

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