Unser JAXenter-Beitrag "Maven - eine Ausgeburt der Hölle" hatte die polemische Kritik von Kent R. Spillner am verbreiteten Build-Manager Maven paraphrasiert - und dabei wohl in ein Wespennest gestochen. Die lange Liste der Kommentare zum Beitrag spiegelt die mehr oder minder leidvollen Erfahrungen mit Maven-Build-Prozessen wider.
Eine Leitfrage, die noch immer nicht aufgelöst scheint, schwebt über der ganzen Diskussion zu den vermeintlichen Stärken und Schwächen der verschiedenen Buildsysteme:
Welche Freiheitsgrade sollen dem Entwickler beim Aufsetzen eines Build-Prozesses zugestanden werden?
Maven - Konfigurationshölle oder Dependency-Himmel?
Die vielfach geäußerte Hauptkritik an Maven ist die, dass Maven-Builds, wie es Kommentator MK ausdrückt, zu "komplex, fehleranfällig und langsam" seien. Das halbe Internet lade Maven herunter, kommentiert auch RPR, und baue dadurch zu viele Abhängigkeiten auf. Unzählige unnötige Ordner würden von Maven verlangt, die dann aber nichts oder nur einen einzigen Eintrag enthielten. Man könne Maven diesbezüglich zwar konfigurieren, doch sei das ein ebenso aufwändiges und zudem schlecht dokumentiertes Unterfangen.Kommentator jiai bestätigt: "Maven funktioniert in den Default-Einstellungen gut", doch:
Sobald man nur beginnt, die Position des lokalen Repositorys zu ändern, ist man aber bereits in der Konfigurationshölle. jiai
Dass bei 99 Prozent der Fälle allerdings genau diese Standardeinstellungen völlig genügen, entgegnet Sascha den Maven-Kritikern. Ja, Maven könne ein Monster sein, wenn man in die Tiefe gehen müsse. Für den normalen Entwickler sei dies allerdings so gut wie nie erforderlich.
Maven definiert eben einen Standard - und gerade dieser Standard hat wohl viele Projekte eher auf einen Weg in den "Dependency-Himmel" geführt:
Wir haben uns vor einigen Jahren für Maven entschieden, weil es uns in der "agilen" Entwicklung aus der Dependency-Hölle befreite. Sascha
“Mit Maven [haben wir es] endlich geschafft, das Bibliothekenwirrwarr auf den einzelnen Entwicklungsrechnern sinnvoll in den Griff zu bekommen. Marc Teufel
Der Standard für die Directorystruktur, der defnierte Ablauf des Builds - das ist meines Erachtens eine gute Sache, es gibt eigentlich so gut wie nie einen Grund, warum das jedes Projekt anders machen sollte. Florain
Wie viel Freiheit braucht ein Entwickler?
Gut, Maven hat einen Standard etabliert - einen Standard, der für einige funktioniert, für andere aber zu wenig Freiheitsgrade erlaubt. Wie viel Freiheit verträgt ein Buildsystem? Die Argumentation von Sascha ist interessant:Erlaubt ein Build-Tool die volle Kontrolle und freie Konfigurierbarkeit des Prozesses, so entfernt man sich immer mehr von einem Industrie-Standard, der Projekt-übergreifend das Arbeiten erleichtert.
Es soll eben nicht die ganze Freiheit geben. Gerade die ist problematisch. Der Vorteil bei Maven ist gerade die deklarative Herangehensweise. Wenn es in einem Build-System auch noch Variablen, Conditions und Schleifen gibt habe ich eine Programmiersprache. Sascha
DevKnight stimmt Sascha in diesem Punkt voll zu:
Flexibilität ist ja schön und gut, aber bisher hab ich noch kein Problem gehabt, was nicht im Maven-Umfeld lösbar war. DevKnight
Außerdem geht es um Standardisierung im Build-Prozess. Ich will doch als Consultant nicht in jedem Projekt ein anderes Build-Tool mit anderen Pradigmen/Strukturen haben. Von daher ist der Maven-Ansatz, viele Dinge zu standardisieren und zu vereinheitlichen, zu befürworten, weil Standardisierung am Ende immer Zeit und damit Geld spart. DevKnight
Flexibilität und Standards miteinander zu vereinen, ist laut Dierk König die Kunst und Lösung für dieses Dilemma. Wem Maven zu starr sei und Ant zu viele Freiheitsgrade erlaube, der solle sich einmal das Groovy-affine Gradle-Build-System anschauen, das dem Entwickler die Möglichkeit belasse, sich an Industriestandards zu halten, an den Stellen, an denen es ihm sinnvoll erscheint, jedoch auszubrechen und flexibel zu konfigurieren.
Gradle lässt Dir die ganze Freiheit - und gibt Dir trotzdem einen Standard (apache maven, hört, hört) vor. Das ist ja gerade der Trick! Man folgt dem Standard, wenn er taugt. Dierk König
Gradle ist ein build-toolkit. Das kann man wohl so sagen. Und ja - man kann programmatisch eingreifen. Anders als bei reinem Ant hat man aber sinnvolle Defaults, die dazu führen, dass man nur dann eingreift, wenn es nötig ist. Dierk König
Eine versöhnliche Erkenntnis trägt Marc Teufel bei, nämlich dass auch das jeweilige Projekt, das man zusammenbauen möchte, zu dem gewählten Ansatz eines Build-Tools passen muss.
Aber auch ich muss zugeben, dass sich Maven bei uns auch nicht für jedes Projekt eignete. So bauen wir unsere Eclipse RCP-Projekte beispielsweise ohne Maven, sondern ausschließlich auf Basis von Ant. Auf Biegen und Brechen geht da gar nichts...blockquote
Ich denke, man muss viel mehr von Fall zu Fall unterscheiden, welches Buildwerkzeug Sinn macht. blockquote
Die Frage steht nun aber immer noch im Raum:
Wie stark sollte ein Entwickler beim Build-Prozess bevormundet werden?
