Apache Buildr Keine Verlinkung Im Text
Total Page：16
File Type：pdf, Size：1020Kb
Buildr Tools Die Maven-Alternative? Wohin mit dem Logo? Apache Buildr Keine Verlinkung im Text. Die Automatisierung der Build-Prozesse ist eine feine und wichtige Sache. In der Regel freut man sich, wenn ein Projekt Apache Maven verwendet und man dank der Konvention das Projekt sofort bauen kann. Doch mit der Zeit stellt sich in der Regel Ernüchterung ein: Der Build schlägt plötzlich fehl, weil ein Artefakt nicht mehr in den bekannten Repositories gefunden werden kann, die Ergebnisse sind nicht exakt reproduzierbar oder für eine kleine Erweiterung des Prozesses müssen erst aufwändig Plug-ins entwickelt und verteilt werden. Muss das so sein? Apache Buildr hat sich zu einer mächtigen Alternative entwickelt, indem es den deklarativen Ansatz von Maven mit dem imperativen einer Skript- sprache kombiniert. von Tammo van Lessen sind die Konfigurationsoptionen verschiedener Plug-ins nicht immer selbsterklärend und ändern sich mitunter Die Ursprünge von Buildr [1] liegen in der BPEL-Engine zwischen Plug-in-Versionen. In der Praxis führt dies zu Apache ODE [2]. ODE ist ein komplexes Middleware- schwer aufzuspürenden Problemen und zu nicht repro- Projekt, das sehr hohe Anforderungen an das Build- duzierbaren Builds. Scherzhaft sprach man sogar vom System stellt. So besteht es aus über fünfunddreißig „Maven Uncertainty Principle“, in Anlehnung an Hei- Modulen, unterstützt neun Datenbanken, wird in drei senbergs Unschärferelation. verschiedenen Editionen paketiert und hängt von über hundertzwanzig Bibliotheken ab. Die Datenbankanbin- Notausgänge dung erfolgt wahlweise über OpenJPA oder Hibernate Dass dies besser gehen muss, steht außer Frage – aber – beide müssen im Build-Prozess berücksichtigt werden. wo genau liegt eigentlich das Problem? Maven verfolgt Die Datenbankskripte sollen nicht nur für eine Daten- einen rein deklarativen Ansatz mithilfe einer XML-ba- bank, sondern gleichzeitig für alle neun erzeugt werden. sierten DSL. Diese DSL ist allerdings ausschließlich in Zusätzlich werden XML-Parser und -Serializer mittels der Lage, das „Was“ zu beschreiben, nicht jedoch das XMLBeans generiert und eigene Annotations-Prozesso- „Wie“. Für die tatsächliche Implementierung der ge- ren für die Codegenerierung verwendet. Dazu kommen wünschten Funktionalität sind die Plug-ins verantwort- weitere „Kleinigkeiten“, wie die Anforderung, dass alle lich. Sie allein bestimmen also das „Wie“. Die einzige ausgelieferten Textdateien, auch die generierten, die Möglichkeit, Einfluss darauf zu nehmen, ist die Konfigu- Apache-Lizenz im Kopf führen müssen. ration der Plug-ins (im Rahmen der angebotenen Funk- tionalität) oder ein Notausgang. Ein solcher könnten „Maven Uncertainty Principle“ z. B. ein selbst geschriebenes Maven-Plug-in, der Aufruf Nach den guten Erfahrungen, die das ODE-Projektteam eines Ant-Scripts oder, wie in Maven 1, ein Jelly-Script mit Maven 1 gemacht hatte, war man optimistisch, auch sein. Die Lösung kann also nur die bessere Verbindung diese Anforderungen mit Maven – diesmal in Version 2 – der deklarativen und imperativen Ansätze sein, die eine umsetzen zu können. Das war auch tatsächlich möglich, nahtlose Integration von Notausgängen erlaubt [3]. allerdings mit deutlich höherem Aufwand als erwartet. Buildr hat sich genau das zum Ziel gesetzt und setzt Für eine so einfache Aufgabe wie das Zusammenführen dabei auf bewährte Mittel. So sollen die guten Eigen- von zwei SQL-Dateien benötigt man beispielsweise 34 schaften von Maven, wie z. B. die Abhängigkeitsverwal- Zeilen XML. Die SQL-Skripte für alle Datenbanken zu tung, beibehalten werden. Als Basis für die DSL wird erzeugen, war mit Maven und Plug-ins gar nicht mög- aber auf XML verzichtet und stattdessen Ruby einge- lich, sodass man an dieser Stelle auf Ant-Skripte aus- setzt. Dadurch hat man jederzeit die Möglichkeit, die weichen musste. Im Ergebnis war die Build-Logik von Mächtigkeit der Skriptsprache als Notausgang zu ver- Apache ODE um insgesamt 6739 Zeilen XML-Code wenden, wenn die deklarativen Elemente nicht mehr gewachsen, verteilt auf 53 Dateien. Die Verteilung auf ausreichen. Der Buildr-basierte Build von Apache ODE mehrere voneinander abhängige pom.xml-Dateien muss besteht nun nur noch aus 912 Zeilen Ruby-Code, der man in Kauf nehmen, wenn man sein Projekt auf meh- Übersichtlichkeit halber auf drei Dateien verteilt. Ein rere Module verteilen möchte. Man kann sich vorstel- wichtiger Nebeneffekt: Der Build-Prozess ist sogar dop- len, dass das auf Kosten der Wartbarkeit geht. Zudem pelt so schnell. www.JAXenter.de javamagazin 1 | 2013 109 Tools Buildr he von Tasks, die den Lifecycles von Maven sehr nahe kommen: • clean: löscht alle während des Builds erzeugten Da- teien • compile: kompiliert das Projekt und seine Unterpro- jekte Abb. 1: Auf der Basis von Ruby setzt Buildr auf Rake auf • 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 Quellda- teien und startet dann automatisch die Kompilierung • release: erzeugt ein Release mit Tag in der Versions- Abb. 2: Abhängigkeiten der wichtigsten globalen Tasks kontrolle und lädt die Artefakte in ein Maven-Repo- sitory hoch Auf der Basis von Ruby setzt Buildr auf Rake auf • junit:report: erzeugt die HTML-Reports für die (Abb. 1). Rake ist ein populäres Build-Werkzeug in der JUnit-Testfälle Ruby-Welt. Es operiert auf einem gerichteten azykli- schen Graphen, um Abhängigkeiten zwischen Tasks zu Abb. 2 zeigt die Abhängigkeiten der wichtigsten Tasks. definieren. Dafür stellt es eine einfache DSL zur Verfü- Abhängigkeiten: Eines der wichtigen Features von gung. Die Tasks selbst werden in Ruby implementiert Maven ist die Möglichkeit, Projektabhängigkeiten auto- und können dementsprechend komplexe Aufgaben be- matisch verwalten lassen zu können. Buildr übernimmt arbeiten. Zusätzlich können so genannte FileTasks kau- dieses Feature und arbeitet mit den gleichen Reposito- sale Abhängigkeiten zwischen Dateien definieren. Wird ries wie Maven zusammen. Die GAV-Koordinaten der eine solche Abhängigkeit zwischen einer .java- und Artefakte werden in der Form group:id:type:version an- .class-Datei definiert, so weiß Rake, dass es die .class- gegeben und in normalen Ruby-Variablen definiert. Mit Datei nur dann neu erzeugen muss, wenn die .java-Datei einigen Hilfsmethoden lassen sich hier elegante Schreib- ein neueres Änderungsdatum als die .class-Datei hat. weisen finden, um komplexe Abhängigkeitsstruktu- Dennoch wurde Rake für die Build-Prozesse von ren einfach auszudrücken. Wichtig ist zu erwähnen, Ruby-Projekten entwickelt. Um effizient Java-Projekte dass Buildr keine komplexe Abhängigkeitsauflösung bauen zu können, liefert Buildr die nötigen Erweiterun- wie Maven unterstützt. Zwar kann man mithilfe der gen der DSL, um die wichtigsten Elemente eines Builds, transitive()-Methode die weiteren Abhängigkeiten her- nämlich Kompilieren, Testen, Paketieren und Releasen, unterladen und verwenden, allerdings ist diese Funktio- Whitepapers360 – deklarativ in der Skriptsprache verwenden zu können. nalität nur rudimentär implementiert. Das ist allerdings Ihre zentrale Anlaufstelle, wenn es auch so gewollt, denn die automatische Auflösung der Die Kernkonzepte Abhängigkeiten hat auch bei Maven immer wieder zu um technische Informationen geht! Projektstruktur: Anders als Maven werden Multi-Mo- Problemen geführt. Besser ist es, die Abhängigkeiten ma- dul-Builds nicht auf mehrere POMs verteilt, sondern in nuell festzulegen. Wer dennoch nicht auf dieses Feature Aktuelle Whitepapers: einer einzigen Build-Datei namens buildfile beschrieben. verzichten möchte, kann die Aether- und Ivy-Plug-ins Dabei können Unterprojekte beliebig häufig verschach- verwenden. Anders als bei Maven ist es jedoch auch sehr telt sein. Buildr geht zunächst davon aus, dass die einzel- leicht möglich, lokale Bibliotheken, beispielsweise aus NoSQL – Beyond the Key-Value Store for the Enterprise nen Projekte der Maven-Konvention, also src/main/java einem libs-Ordner im Projektverzeichnis, zu verwenden. für Java-Code, src/main/resource für Ressourcen, src/ Bauen: Buildr unterstützt nicht nur Java, sondern auch Turbo-Charge Applikation Performance To SQL Server test/java für Java-Tests, src/test/resources/ für Testres- Groovy, Scala und Ruby, zusammen mit ihren wich- sourcen etc. folgen. Es lassen sich aber auch andere tigsten Testframeworks. So können Java-Projekte ohne Projektlayouts konfigurieren. Analog zu den GAV-Ko- weiteres Zutun mit JUnit, TestNG oder JBehave getestet High Performance leicht gemacht ordinaten der Maven-Projekte (Group, Artifact, Versi- werden. Die Kompilierung der Quelldateien lässt sich on) werden jedem Projekt eine artifactId, eine groupId sehr leicht um zusätzliche Tasks, etwa zur Codegenerie- Vom Angriff zur Abwehr: Ein Leitfaden zum Schutz von und eine Version zugewiesen. Für jedes Projekt (und die rung, erweitern. Ebenfalls Teil des Bauens ist das Kopie- Unterprojekte) definiert Buildr automatisch eine Rei- ren und Verarbeiten der Ressourcen. Wie auch Ant und Softwareprodukten vor den 8 häufi gsten Angriff sszenarien Mehr Informationen: www.whitepapers360.de 110 javamagazin 1 | 2013 www.JAXenter.de Buildr Tools Maven erlaubt es Buildr, die Dateien während