Ich hatte schon an anderer Stelle gesagt, dass ich von vielen grundsätzlichen Ideen, die hinter Maven stecken, glaube, dass sie gut und sinnvoll sind. Die Wunschvorstellung, beliebige Programmteile standardisiert aus dem Netz abgreifen zu können, hatte ich schon als Java gerade erst erwachsen wurde. Aber so toll, einfach und elegant das mit Maven im Idealfall sein mag, so unerreichbar ist der Idealfall in der Praxis, und so unschön sind die tatsächlichen Ergebnisse.
Der Versuch, den ich da gestartet hatte, war ja freiwillig - einfach nur so, es zwingt einen ja keiner. Und ich wollte es Maven wirklich recht machen. Aber dann: distributionManagement festlegen, weil's in einer lokalen Datei landen soll - äh - ja, OK. TagBase festlegen weil die "trunk/branches/tags"-Struktur bei SVN offenbar von den Conventions abweicht, die Maven einem auferlegt, ... naja, OK. Aber so eine vermeintliche Trivialität wie das Hinzufügen von Source und JavaDoc zum JAR, die ans Unmögliche zu grenzen scheint - warum sollte man sich sowas antun?
Es ist ja toll, wenn man für ein "komplett konventionelles" Projekt nur eine 3-zeilige POM braucht. Aber für ein trival-Projekt, das ich gezielt für Maven anlegen wollte, bin ich jetzt bei ca. 130 Zeilen. Davon habe ich nur einen Teil verstanden, und die 80 auf 2 Dateien verteilten Zeilen, die du gepostet hast, sind noch nicht dabei. Es ist nett, dass du dir diese Arbeit gemacht hast, aber ehrlich: Ich WILL das nicht - das ist doch ein Krampf?! :noe: Und das nur weil ich gerne eine JAR hätte, wo alles drin ist, was man braucht, und die man so direkt auf eine Webseite hochladen kann. So unnormal oder viel verlangt ist das doch nicht...
Ich hasse übrigens XML nicht. Es ist ziemlich "verbose", aber durch seine Struktur eben sehr allgemein und durch Bibliotheken leicht zu verarbeiten. Ich finde aber, dass es an vielen Stellen eingesetzt wird, wo es nicht sinnvoll ist. XML beschreibt eine
Struktur, aber keinen
Ablauf. Für die "Paradedisziplin" von Maven (was wohl das Dependency management ist?!) ist das schön, aber IMHO nicht für einen Build-Prozess. Vermutlich wurde das einfach von ANT geerbt? Naja, wenigstens keine Lochkarten mehr...
Das ist aber unabhängig davon, dass man das Ziel "Convention over Configuration" nicht dadurch erreichen sollte, dass man die "Configuration" praktisch unmöglich macht - das ist dann nämlich nicht eine Ermutigung dazu, Konventionen einzuhalten, sondern IMHO schlicht unflexibel. Wie bei einer API: Einfache Dinge sollten einfach sein. Schwierige Dinge können schwierig sein. Und wenn es mit einem build-Tool schwierig ist, eine "vollständige" JAR zusammenzupacken, dann ist das schlecht, und läßt (zumindest für mich) die Einfachheit anderer Dinge bedeutungslos werden.
(Die Einfachheit wird ohnehin nur suggeriert, weil die Dinge nur dadurch einfach werden, dass man die fehlende Flexibilität antizipiert und damit die Aufgaben zu computergerecht stupiden und automatisierbaren Abläufen degenerieren. Das ist nicht schlechtes, im Gegenteil, das MUSS man bei komplexeren Softwaresystemen so machen - aber gerade bei denen sollte man doch auch die Möglichkeit haben, darauf zu reagieren, dass die Welt eben nicht perfekt ist, und diese Möglichkeit sehe ich bei Maven nicht. Ich wünsche zumindest niemandem, dass er mal kurz vor einer deadline feststellt, dass er in seiner 20KB-POM (die von einer anderen POM erbt, damit sie nur 20 und nicht 40 KB hat, und die noch ein paar andere XMLs referenziert, und auf irgendwelche abstrusen Settings zurückgreift) noch irgendeinen Fehler suchen muss...)
Ich werde mir Maven (und/oder Gradle & Co) vielleicht nochmal anschauen, wenn ich mal vieeel Zeit habe, aber ... der Aufwand, sich in Maven ernsthaft einzuarbeiten steht in keinem Verhältnis zu einem Klick auf "Create JAR" im Eclipse-Menü - da kann man nämlich eine Checkbox auswählen, um Sources und JavaDocs mit dazuzupacken...
