Interaktiver Build-Vergleich: Teil 3 – Apache Maven

Im dritten Beitrag unseres interaktiven Build-Vergleichs zwischen Maven, Ant und Gradle kommt das Apache-Maven-Projekt vor unsere Linse. Gestartet als Subprojekt des „Rapid Development Web Application Framework“ Apache Turbine im Jahr 2002, hat sich Maven schnell emanzipiert und wurde 2003 als Top-Level-Projekt bei Apache angenommen. Maven führt den Ansatz „Convention over Configuration“ konsequent in den Java-basierten Buildprozess ein: Die Idee ist, ein Großteil der nötigen Einstellungen über standardisierte Vorgaben (Conventions) zu regeln, die vom Entwickler lediglich angepasst werden sollen (Configuration).

Die erste Major-Version 1.0 von Maven erblickte 2004 das Licht der Welt, gefolgt von Maven 2 im nachfolgenden Jahr. Kurz vor der Vollendung steht derzeit die dritte Neuauflage des Build-Tools, von der Maven-Gründer Jason van Zyl sagt, dass es das „beste Maven aller Zeiten“ sein wird. In unserem Build-Vergleich lässt sich Jason van Zyl von Matthew McCullough vertreten, langjähriger Mitstreiter im Maven-Projekt, der sich unseren einleitenden Fragen gestellt hat.

JAXenter: Hallo Herr McCullough! Worauf wurde (und wird) bei der Entwicklung des Maven-Build-Systems besonderen Wert gelegt?

Matthew McCullough: Der Hauptfokus von Maven liegt darauf, eine möglichst kohärente und einfache Out-of-the-Box-Lösung für Java-basierte Builds bereit zu stellen, die Code-Kompilierung, Dependency-Management, Unit Testing, Archiv-Produktion (JAR, WAR oder EAR), Projekt-Reports und Bedienbarkeit von einem Continuous-Integration-Server aus benötigen.

Diese Zielvorgabe findet oft Anklang in großen Organisationen und Unternehmen, wurde aber auch sehr gut in der Open Source Community aufgenommen. Wirft man einen kurzen Blick auf die Anzahl der Projekte bei Apache, die Maven einsetzen, erhält man eine Bestätigung für die Beliebtheit Mavens und der Klarheit, die ein Maven-Build für Unternehmen und das Kompilieren eines Produktes ermöglicht. Fast ohne Zusatzaufwand, was das Schreiben von XML angeht, erhalten Maven-Anwender Projekt-Reports über den Verlauf von JUnit-Tests, Code Coverage, JavaDoc, HTML-formatierten Quellcode, statische Analysen und vieles mehr. Für viele der üblichen Arbeitsprozesse ist die Projekt-Definitions-XML bei Maven minimal gehalten. Und für Entwickler, die in diesen Ressourcen-sensiblen Zeiten an mehr als nur einem Projekt arbeiten, ist die starke Konsistenz des Projekt-Objekt-Modells (POM) von Maven ein rettender Anker, um schnell die Builds vieler verschiedener Systeme zu verstehen.

Das oben genannte Hauptziel von Maven wird dadurch unterstützt, dass für Maven die größte Anzahl an qualitativ hochwertigen Plug-ins für Continuous Intergration Server wie Hudson oder Bamboo bereit steht. Tatsächlich kann ein Maven-Build fast mühelos in Hudson eingebunden werden, indem man Hudson lediglich auf die Projekt-POM in einem via Http zugänglichen Repository weist. Der Ort des Quellcodes wird von der POM aufgenommen, ebenso wie die zu kompilierenden Source-Pattern sowie die Klassen, welche als Unit-Tests ausgeführt werden sollen, und die Abhängigkeiten, welche heruntergeladen und gebündelt werden müssen. Alles in allem macht Maven das Aufsetzen eines Builds zu einer angenehmen Angelegenheit für jeden Build-Ingenieur, indem es deskriptive (nicht imperative), verbindliche Definitionen gemeinsamer Build-Facets, Objekt-orientierte Vererbung von Build-Eigenschaften und feste Default-Einstellungen für Elemente wie Quellcode-Locations bietet.

JAXenter: Wo sehen Sie die Stärken von Maven im Vergleich zu anderen Build-Systemen?

Matthew McCullough: Mavens besondere Stärke liegt vor allem in seinen fixen Konventionen, welche sich in einem Zeitraum von acht Jahren als gewünschter Industrie-Standard herauskristallisiert haben. Build-Skripte sind in den meisten Fällen nicht der Ort, an dem Entwickler ihre größte Kreativität ausdrücken sollten. Technische Fähigkeiten sollten besser beim Schreiben der Software-Produkte selbst demonstriert werden. Maven ermöglicht es, dass Entwickler weniger Zeit mit dem Build-Skript verbringen müssen als mit jedem anderen Build-Werkzeug, weil z.B. Builds für verschiedene Systeme die meisten Konfigurationen von einem Parent-Skript über echte Objekt-orientierte Vererbung ableiten können.
Ich habe in meinem Leben viel zu viele Skripts gesehen, die eher eine chaotische Kakophonie aus kleinen Elementen darstellten, als eine wohlgeordnete Symphonie aus Plug-ins in einer vorhersehbaren Sequenz des Software-Lebenszyklus – einfach deshalb, weil das verwendete Build-System dem Build-Skript, wenn überhaupt welche, dann nur wenige Grenzen gesetzt hat. Mein Kollege David Bock von „No Fluff Just Stuff“ zitierte kürzlich Neal Ford auf der RailsConf 2010, der sagte: „Grenzen können eine befreiende Wirkung haben.“ Ich glaube, dass Maven stark diesem Grundsatz verpflichtet ist.

Ein weiterer Aspekt ist, dass Maven durch die Vererbung von Projekt-Objekt-Modellen (wie oben erwähnt) sowie durch so genannte „Archetypen“ (mächtige, interaktive Projekt-Templates) die Notwendigkeit vermeidet, Build-Skripte über die fehleranfällige Copy-and-Paste-Methode zu erstellen. Es gibt heute über 100 Archetypen im zentralen Maven Repository, die alle über einen einfachen Maven-Dialog zugänglich sind. Jeder Archetyp fragt nach dem Java Package und Projektnamen und instatiiert ein qualitativ hochwertiges Projekt, welches in ein Versionskontrollsystem eingebunden und um neuen Quellcode erweitert werden kann. Dies verringert die Gefahr, beim Copy-and-Paste in ein neues Build-Skript aus Versehen zu vergessen, alle Vorkommen von „Blauer Kunde“ in „Roter Kunde“ umzubenennen – und damit die Verlegenheit, wenn der falsche Name dann bei der ersten internen Demo von einem Projektor an die Wand geworfen wird.
Zu guter Letzt ist Maven Erfinder und Inhaber des kanonischen Dependency Repository Formats. Ant, Ivy, Gant, Gradle und sogar die kommenden Grails-Dependency-Management-Systeme folgen diesem Standard und nutzen das Repository Layout und die Zentralisierung von Artefakten, die Maven bereitstellt. Dies ist eine Bestätigung dafür, dass in http://repo1.apache.org/maven2 acht Jahre Erfahrung und Wertschöpfung eingeflossen sind, von denen sowohl Maven als auch andere Build-Tools noch viele Jahre lang profitieren werden.

Interaktiver Build-Vergleich: Spielregeln
1. Runde: Wir stellen die drei selben kurzen Fragen an je einen Vertreter von Maven, Ant und Gradle.
2. Runde: Geben Sie über die JAXenter-Kommentarfunktion Ihr Feedback zurück an die Build-Experten!
3. Runde: Die Build-Experten reagieren auf Ihr Feedback und beantworten Ihre Fragen!
Darüberhinaus können Sie uns Ihre Erfahrungen mit den Buildtools auch anhand der folgenden Fragen mitteilen:
1. Mit welchen Build-Systemen haben Sie in Ihrer Praxis bereits Erfahrungen gesammelt?
2. Wo sehen Sie die Stärken Ihres bevorzugten Build-Systems?
3. Wo sehen Sie Schwachpunkte der anderen Build-Systeme?
4. Welche Fragen haben Sie an Matthew McCullough (zu Maven), Hans Dockter (zu Gradle) und Jan Matèrne (zu ANT)?

JAXenter: Was kann Maven von anderen Build-Systemen lernen?

Matthew McCullough: Ich sehe drei Dinge, welche für das Maven-Ökosystem bzgl. der Ansätze und der Verbreitung anderer Build-Systeme bedeutsam sind.

Der erste Punkt ist die Beobachtung, dass Library-Dependency-Management, und sogar weiter: transitives Dependency Management, eine große aber notwendige Herausforderung ist, die sich allen modernen Anwendungen stellt, und von den Build-Systemen gelöst werden muss. Maven hat die Anstrengungen an dieser Front in den letzten acht Jahren angeführt und ein zentrales Repository bereit gestellt, welches über die letzten Jahre qualitativ kontinuierlich gereift ist und im letzten Jahr dramatische Verbesserungen durch Sonatypes Möglichkeiten des OSS-Hosting und -Mirroring erfahren hat.

Die zweite Beobachtung ist, dass je mehr Kanäle man einer Community zur Verfügung stellt, desto mehr Feedback die Community auch beisteuern wird: Vorschläge, Testen, Bugfixing etc. Was Maven anbelangt, mit seinen vielen Zusatzprojekten auf GitHub, ist die Hürde für eigene Beiträge so niedrig wie sie technologisch heute überhaupt nur sein kann. Es ist ohne weiteres möglich, seinen eigenen Projekt-Fork zu starten, neuen Code oder Bugfixes beizutragen und dann einen Pull Request an das Core-Entwicklerteam zu senden. Keine Patches und manchmal auch keine JIRAs sind nötig – einfach schnelle Community-Beiträge.

Drittens: Andere Build-Systeme haben die Lust der Community aufgezeigt, ein Werkzeug in kleinen, nachvollziehbaren Schritten zu erweitern. Ein neues Maven Plug-in kann die richtige Wahl sein, aber manchmal können auch kleinere Verbesserungen angebracht sein. Heute nehmen diese kleinen Verbesserungen die Form von importierten abgegrenzten Dependencies, Vererbungen, Archetypen, antRun-Skripts und gmaven-Skripte an. In der nahen Zukunft werden noch Polyglot Macros, POM Mix-ins und zuschaltbare Provider für Facet-artige settings.xml-Dateien hinzukommen.

Während ich selbst im Bereich der Build-Werkzeuge stark beim Maven-Projekt engagiert bin, möchte ich aber doch allen Entwicklern danken, die Beiträge zu Maven, Ant, Gant, Rake Buildr oder Gradle leisten. Denn diese Entwickler ermöglichen es letztlich, dass im Wettbewerb der Build-Tools für die JVM ein gesundes Ökosystem aus verschiedenen hochwertigen Build-Optionen entsteht, in dem die Entwickler nur als Gewinner hervorgehen können.

JAXenter: Vielen Dank für diese Ausführungen!

Matthew McCullough: Vielen Dank, dass ich in dieser Vergleichsaktion den Maven-Part übernehmen konnte!

Matthew McCullough ist Mitgründer von Ambient Ideas, LLC und verfügt über 14 Jahre Erfahrung in den Bereichen Enterprise Software Entwicklung, Open Source Entwicklung und Beratung. Matthew ist Mitglied des JCP, Sprecher auf Konferenzen (No Fluff Just Stuff tour), Autor zahlreicher Publikationen, u.a. auf DZone Maven. Seine aktuellen Interessen umfassen Cloud Computing, Service Integrations, Maven, Git, und Hadoop.

Geschrieben von
Kommentare

Schreibe einen Kommentar

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