vienna.in-a-nutshell.net

Ich habe mir gestern und heute Maven2 näher angeschaut, weil ich es für ein Projekt verwenden wollte, indem ich vorerst der einzige Entwickler bin. Maven2 ermöglicht eine deklarative Beschreibung des Build-Prozesses und ist für Java-Projekte ausgelegt. Da es dem Prinzip “Convention Before Configuration” bleiben die XML-Dateien (pom.xml, settings.xml, etc.) die man zu schreiben hat bei einfachen, standardkonformen Projekten zum Unterschied von Ant klein und übersichtlich. Maven2 behält Überblick über die Abhängigkeiten zwischen den einzelnen Moduln. Zum Unterschied von Maven1 werden sogar transitive Abhängigkeiten berücksichtigt. Sogar das Downloaden von externen Moduln übernimmt Maven. Für Maven2 existieren schon zahlreiche in Java geschriebene Plugins die Maven2 erweitern. Maven2 generiert so nicht nur ein jar (bzw. war, etc.) - File sondern führt auch die junit-Test automatisch durch und generiert auf Wunsch eine Projekt-Homepage mit zahlreichen Reports. Maven2 übernimmt das automatisch Signieren und erstellt jnlp-Dateien und vieles andere mehr. Und natürlich kümmert sich maven2 auch um den automatischen Upload. Von diesen Möglichkeiten jetzt zu meinen perönlichen Erfahrungen.

Ich verwende Eclipse. Bei der Kombination von Maven und Eclipse ist folgendes zu beachten:

* mvn eclilpse:eclipse Dieser Befehl ruft das “Maven Eclipse Plugin”, das daraufhin die Eclipse Projekt-Einstellungen anhand der Maven-Deklarationen generiert.

* Mevenide bietet ein Eclipse-Plugin, um Maven1 in Eclipse zu integrieren

* m2eclipse plugin von Mergere ist ein Eclipse-Plugin für Maven2. Es beschränkt sich auf wenige Features. (maven per Kontext-Menü aufrufen und dessen Output im Console-Fenster von Eclipse lesen. Editor für Mavens pom.xml) Aber während meiner ersten Schritte habe ich es als praktisch empfunden.

* flaches Projektlayout. Wenn man sich den Package-Explorer von Eclipse ansieht, dann sind dort alle Projekte im selben Workspace. Keine Projekte sind in sich geschachtelt, wie das bei Maven-Projekten durchaus üblich ist. Dieses flache Layout kann man allerdings recht problemlos auch bei eigenen Maven-Projekten verwenden.

Trotzdem bin ich zu dem Schluß gekommen Maven2 es vorerst nicht zu verwenden. Hier die Gründe:

Allen voran:

• 1. Wie in Maven2 auch empfohlen teile ich meine Projekte in viele Moduln auf, wobei jedes Modul in meinem Fall einem Projekt in meinem Eclipse-Workspace entspricht. Wenn außer mir niemand die Sourcen verändern darf habe ich jederzeit die Möglichkeit projektübergreifende Refactorings vorzunehmen. Mit den Refactoring-Funktionen von Eclipse macht das wirklich Spaß. Wenn ich die Projekteinstellungen von dem Eclipse-Plugin für Maven2 erstellen lasse scheint das nicht mehr zu funktionieren. “Project/Properties/Java Build Path/Projects” bleibt in diesem Fall leer, womit das projektübergreifende Refactoring nicht mehr klappt.

Hier noch ein paar weitere Kritikpunkte:

• 2. Abgesehen von dem kostenlosen eBook “Better Builds With Maven” und den Hinweisen auf der Maven2 Website gibt es recht wenig gute Dokumentation. Die Fehlermeldungen von Maven2 bzw. seinen Plugins lassen (noch immer, Stand Juni 2006) zu wünschen übrig. Wenn ich schon in den ersten Stunden der Nutzung den Source-Code eines Programmes zu lesen beginne, weil ich anders nicht weiter komme, dann spricht das nicht unbedingt für diese Sofware.
• 3. Ein vollständiges “best practice” Beispiel für Maven+Eclipse+SVN fehlt eindeutig.
• 4. Die öffentlichen Maven-Repositories sind recht unvollständig und werden IMHO schlecht gewartet. Weder glazedlists-1.6.1 noch glazedlists-1.6.0 habe ich gefunden. glazedlists-1.5.0 war die aktuellste Version. Aber das scheint keine Ausnahme sondern die Regel zu sein. In diesem Fall muss man selbst Repositories anlegen.
• 5. Rein theoretisch sollte man ein Maven Projekt ohne weiteren Aufwand mit einem Befehl auf der eigenen Plattform compilieren können. Da ja fehlende Libraries automatisch nachgeladen werden. In der Praxis ist es dann doch nicht so einfach: Viele Libraries (auch von sun) dürfen nicht einfach so zum Download angeboten werden, sondern dürfen nur von der Original-Website nach dem Akzeptieren der Lizenz-Bedingungen heruntergeladen werden. Damit wird es erst recht sehr mühselig.

Am Horizont tauchen neue Java-Erweiterungen auf (JSR 277, etc.) und oft liest man, dass User von Sun fordern, selbst Features zu standardisieren (bzw. zu implementieren), die mavens Repository-Funktionalität entsprechen.

Ich bin überzeugt davon, dass maven2 Probleme zu lösen versucht, die sich den meisten Entwickler stellen. Ob maven die Zukunft wird, das wird nicht zuletzt von den verfügbaren Tools und der Usability von maven abhängen. Ich finde: Es sollte auch für kleinere Projekte attraktiv werden maven zu nutzen.

PS: Kommentare zu Punkt 1 würden mich besonders interessieren.

This entry was posted on Sunday, July 2nd, 2006 at 12:25 and is filed under de: IT. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.