Sicherlich unvollständig und subjektiv - aber teilweise von Team-Kollegen aus Projekten bestätigt.
Und klar, es gibt für alles eine (mehr oder weniger aufwändige) Abhilfe - aber wieso kein Tool, das "out of the Box" nur die positiven Eigenschaften der beiden Dinger verbindet?
Ich bin an Kommentaren interessiert, an den Erfahrungen anderer, und kann auf Nachfrage natürlich einzelne Punkte erläutern...
Ant:
- Guter und stabiler IDE Support(insbesondere Eclipse)
- relativ leicht erweiterbar durch Python-Scripting (kann nervig werden und schwer zu debuggen) und Schreiben eigener Tasks (ist dann ein bisschen mehr Aufwand
- Eigentlich alle Funktionen gut und umfangreich dokumentiert. Frei und online, und als Printversion.
- Erfordert keine weitere Infrastruktur
- Die genutzten Bibliotheken sind ganz klar und fest definiert - dafür hat man, wenn man in einer Firma mehrere Java-Projekte hat, halt auch viele Redundanzen und Binaries im SCM.
- Volle Flexibilität - man muss aber auch alles selbst machen - man kann natürlich Vorlagen entwickeln und nutzen - aber die kommen auch nicht von selbst
- Von Projekt zu Projekt unterschiedlich aussehende Projektverzeichnisse
- Ist aber auch eine Frage der Disziplin. Und Evolution und Weiterentwicklung will man ja auch nicht verbieten.
- Build-Files werden sehr komplex - man kann sie aber auch gut strukturieren und regelmäßiges Refactoring ansetzen
- Eclipse Support eher so la la - andereseits - was geht, das geht. Aber das Maven 1 Plugin war irgendwie besser, hatte auch Eingabehilfen für die ganzen Projekteigenschaften, die man jetzt alle im XML händisch eingeben muss. Das von vielen genutzte MyEclipse unterstützt es (bis zum letzten mal, als ich reingeschaut habe) auch noch nicht
- Saubere Projektstruktur vorgegeben - aber: wo ist mein "doc" Verzeichnis mit README.txt und anderen wichtigen, schnell zugreifbaren Infos in Plaintext - stattdessen gibt's src/site/resources/...
Und woher wissen die Maven Entwickler, was für mich das Beste ist? - Viele wichtige Funkionen für den Build-Zyklus mitgeliefert - will man diese aber anpassen, geht dies teilweise nur, wenn der Plugin-Entwickler das vorgesehen hat - wenn nicht, muss man schon etwas tiefer einsteigen.
- Doku für das Tool selbst und die Plugins nicht so umfangreich und gut wie bei Ant. Und: gibt es ein(gutes und aktuelles) Buch in Druckform? Wie viele davon?
- Will man genau kontrollieren, welche Bibliotheken man für das ganze Projekt nutzt (zum Beispiel verhindern, irgendwelche Snapshots und Alpha-Versionen zu nutzen), hat man einiges zu tun.
- Auschecken und sofort geht nur, wenn man Internet hat, oder einen kompletten Mirror aller wichtigen/genutzten Maven Repositories(und auch oder gerade bei großen Firmen gibt es manchmal Probleme, "mal eben" einige GB und einen Server für einen Mirror zu bekommen.
"Fazit"(falls man es so nennen kann): optimal ist irgendwie keines von beiden, und daher wird mir beim nächsten Mal, wenn ich mich für eines entscheiden muss beim Aufsetzen eines neuen Projektes, die Entscheidung nicht gerade leicht fallen.
Was ist mit
Hat sich die mal jemand angeschaut?
2 comments:
Eine schöne Eigenschaft von Ant ist die breite Unterstützung durch Dritte. Was ich damit meine sind die AntTasks für andere Dinge als die üblichen Java Themen. Zum Beispiel eine gute Adobe-Flex-Unterstützung oder die Open-Source-Alternativen zu Flash MTASC/SWFMill. Es ist auch nicht schwer auf der Basis der existierenden Tasks und deren Sourcen eigene Tasks für irgendwelche Kommandline Tools zu schreiben, die noch nicht unterstützt werden.
Im Prinzip kann man natürlich auch für Maven eigene Mojos erstellen nur ist dafür die Dokumentation deutlich spärlicher/unvollständiger/verwirrender/(vor einiger Zeit zumindest auch fehlerhafter) und damit der Zeitaufwand deutlich höher.
Sehr "nervig" empfand ich die Informationsbeschaffung zu Maven 2. Es gab zwar etliche Treffer bei Google, viele der Information bezogen sich aber auf Maven 1 und waren damit wegen der deutlichen Umbauten vollkommen wertlos, nur war leider oft nicht erkennbar ob eine Seite sich auf Maven 1 oder 2 bezog. Selbst die offizielle Mavenseite war damals (vor ca. 2 Jahren) ein einziges Chaos aus Informationen zu Maven 1 und 2 und broken Links (Obwohl die Dokumentationssite mit Maven erstellt worden war...).
Trotzdem hat mir damals Maven nach allen Geburtswehen gut gefallen. Hat man häufig die selben Projektstrukturen lohnt sich sicherlich der Aufwand der Einarbeitung und Erstellung der Infrastruktur für Maven, um hinterher mit klaren und wiederverwendbaren (vererbbaren) Strukturen Zeit und Nerven zu sparen.
Ja, das bestätigt dann auch ungefähr meinen Eindruck - nur dass ich vielleicht noch ein paar mehr Projekte mit Maven machen muss, um es wirklich gut zu finden und in den vollen Genuss der Stärken zu kommen :)
Vielleicht 'ne interessante Idee, dabei dann gleich zu allen Dingen, die einem als nicht oder schlecht dokumentiert auffallen, und in die man sich einarbeiten muss, die passende Doku zu schreiben und in freier online Form, oder sogar als Buch zur Verfügung zu stellen...
Post a Comment