Ein paar Punkte fallen allerdings immer wieder unangenehm auf. Aus ihnen kann man schnell und einfach ein paar best practices ableiten:
- Keine Snapshot builds.
Maven gibt nicht umsonst eine Warnung aus. Wenn es sich gar nicht vermeiden läßt, dann sollte man auf alle Fälle einen halbwegs getesteten Snapshot verwenden und den manuell im Repository bereitstellen. - Grosse Teams brauchen einen Proxy.
Je größer das Entwicklungsteam ist, desto eher sollte man über einen maven proxy nachdenken. Eine stabile und brauchbare Lösung kommt von Codehaus (http://maven-proxy.codehaus.org/). Nett ist, dass man diesen sowohl standalone als auch als WAR auf nahezu jedem beliebigen Appserver betreiben kann. - Modulabhängigkeiten sind böse.
Modulabhängigkeiten mit maven machen einfach keinen Spass. Vor allem dann nicht, wenn man aus maven heraus mit bspw. eclipse:eclipse auch die Entwicklungsumgebung und ihre Abhänigkeiten definiert. Bei jeder Änderung eines Moduls sind potentiell andere Module betroffen. Für das Neuanlegen/Updaten der Entwicklungsumgebungen geht ganz schön viel Zeit drauf. Allein das sollte Grund genug sein, die maven Module entlang den Softwarekomponenten zu schneiden. Damit macht man den Entwicklern auch das (ungewollte) Verweben der Komponenten schon beim Build sehr unangenehm. Es ist damit quasi ein pre-build-dependency check :) - Maven ist nicht ant.
Wer lange Jahre mit ant seine Projekte gebaut hat, der kommt mit maven erfahrungsgemäß nicht sofort klar. Die Dokumentation von maven ist sehr verstreut und die tatsächlichen Fähigkeiten muss man sich doch in der Praxis erarbeiten. Es empfiehlt sich, dass im Projekt ein Verantwortlicher mit maven Erfahrung regelmäßig überprüft, ob und wie man was besser machen kann.
Darüber hinaus gibt es Dinge, die man mit maven einfach nicht machen kann. So kann man pro Modul bspw. nur ein Artefakt (*.jar, *.war, etc.) erzeugen. Benötigt man mehr, dann muss man tatsächlich auf ant zurückgreifen - Maven und Opensource lieben sich.
Abseits von Opensource Entwicklungsumgebungen wird der Einsatz von maven schnell unbequem. Setzt man beispielsweise auf WebSphere, Bea und Co, dann fehlen einem die gewohnt kompfortablen ant Targets zur Erstellung von Deployment Descriptoren und Ähnliches. Auch wenn es für den RAD schon ein goal im maven gibt. Hier muss man tatsächlich noch ein wenig investieren, damit auch auf weniger quelloffenen Umgebungen eine nahtlose Integration möglich ist.
Soviel für Heute. Mehr in den kommenden Woche, wenn Zeit bleibt.
