JAXenter: Beim Umstieg von Maven 1.x auf 2 sind einige grundlegende Veränderungen gemacht worden. Mit wie viel Migrationsaufwand haben die Anwender von Maven 2 auf Maven 3 zu rechnen?
Jason van Zyl: Unser Ziel ist es, dass Maven 3.0 in den meisten Fällen als einfaches Drop-in-Replacement für Maven 2.x funktionieren wird. Wir haben lange Zeit an der Rückwärtskompatibilität gearbeitet und gleichzeitig einen großen Teil der internen Strukturen von Maven neu implementiert. Bei der Verwendung aus der Kommandozeile versuchen wir eine volle Kompatibilität zu erreichen. Maven 3.0 wird keine doppelten Abhängigkeiten oder Plug-in-Deklarationen zulassen, solche Probleme müssten also behoben werden. Aber davon abgesehen werden keine Veränderungen der POMs nötig sein. In allen anderen Bereichen haben wir Kompatibilitätsschichten geschrieben, die die Anwender vor den vielen internen API-Veränderungen schützen, die wir durchgeführt haben. Ich hoffe wirklich, dass die Maven Community ohne Unannehmlichkeiten zu Maven 3.0 übergehen kann und von den neuen Features profitieren wird.
Weitere Teile dieses ausführ-lichen Interviews mit Jason van Zyl finden Sie im aktuellen Java Magazin und Eclipse Magazin.
JAXenter: Wird es noch eine settings.xml geben oder wird es eine andere Art der Konfiguration in Maven 3 geben?
Jason van Zyl: Auch in diesem Punkt werden wir in Maven 3.0 versuchen, die Modelle nicht zu verändern, an die die Anwender gewöhnt sind. Intern werden wir in Maven 3.1 einen Security Manager integrieren und die settings.xml-Implementierung als Default-Implementierung nutzen. Sonatype plant jedoch die Entwicklung einer Implementierung, die mit Nexus, unserem Repository-Manager interagieren kann. In der Arbeit mit vielen großen Unternehmen haben wir bemerkt, dass die Integration Haus-interner Sicherheitssysteme und kundenspezifischer Implementierungen nötig ist, sodass wir einen Extension Point dafür mit dem Security Manager bereitstellen werden.
In Maven 3.1 werden wir auch POM-Mixins einführen, die dabei helfen, Konfigurationen besser wartbar und portierbar zu machen. Eine der häufigen Klagen zu Maven 2.0 ist, dass das gemeinsame Nutzen von Konfigurationen nur über Vererbung realisiert werden kann. Dies ist offensichtlich problematisch, da nicht alle Projekte innerhalb eines Unternehmens, und sicherlich nicht alle OSS-Projekte, eine Vererbungshierachie teilen. POM-Mixins sind eine Art POM-Komposition, bei denen ein parametrisiertes Fragment in das aktuelle POM über eine einfache Referenz injeziert werden kann.
Mein erstes Mixin wollte ich persönlich zu dem Zweck erstellen, eine standardisierte Release-Funktionalität für Maven-Projekte zu kapseln. Apache-Projekte, die Maven nutzen, erben das Apache POM, welches die Konfiguration für unseren Release-Prozess enthält. Dies umfasst die Lizenz-Zuweisung, PGP-Signierung, Staging und die Anbindung an Nexus, ein Apache-konformes Quellenarchiv, welches die ursprüngliche Projekt-Struktur enthält, sowie die Erzeugung der Standard-Quellen und Javadoc JARs. Ich wollte eine sehr einfache Möglichkeit zur Verfügung stellen, damit jedes Projekt von dieser Funktionalität profitieren kann. Das Release-Mixin besteht aus Plug-in-Deklarationen, ihren parametrisierbaren Konfigurationen und einer Spezifizierung, welche POM-Elemente im Ziel-POM benötigt werden, damit das Mixin korrekt funktionieren kann. Die POM-Mixins können dann in ein Remote Maven Repository deployt und über die Standard Maven Coordinates (genaue Bezeichnung des Artefaktes) gemeinsam genutzt werden. Im Ziel-POM spezifiziert man die Maven Coordinate des POM-Mixin mit den vom POM-Mixin benötigten Parametern. Maven holt sich dann das POM-Mixin zurück und injiziert es in das Ziel-POM.
Was ich erwarte ist, dass in der Community Projekte entstehen, die Mixins für Funktionen bereitstellen, welche die Interaktion vieler Plug-ins mit den passenden Konfigurationen verlangen. Eines der größten Probleme von Maven, angesichts seiner verteilten Natur und der Vielzahl an existierenden Plug-ins, ist es, die richtigen Plug-ins zu finden, die gut miteinander zusammenarbeiten, sowie herauszufinden, wie die verschiedenen Plug-ins konfiguriert werden müssen, um das gewünschte Ergebnis zu erzielen. POM-Mixins werden viele dieser Schwierigkeiten beheben.
JAXenter: Im Maven-Repository finden sich unzählige Plug-ins, von frühen Alpha-Versionen bis zu stabilen Plug-ins, so dass man hier leicht die Übersicht verliert. Gibt es Bestrebungen, das kleine „Plug-in-Chaos“ mit Maven 3 in den Griff zu bekommen? Könnte man sich zum Beispiel vorstellen, ähnlich wie Eclipse, einen Incubator-Prozess und Simultan-Releases mit stabilen Plug-ins anzubieten?
Jason van Zyl: Diesen Punkt plant Sonatype in der nahen Zukunft anzugehen, indem wir eine Menge von qualitativ hochwertigen Plug-ins bereitstellen werden. Aufgrund der verteilten Natur von Maven ist es schwierig für uns, für alle Maven Plug-ins in jedem Maven-Repository auf der Welt eine hohe Qualität zu garantieren und zu kontrollieren, was schließlich in das Maven Central Repository gelangt. Was wir allerdings tun können, ist eine kleinere Menge von Plug-ins auf Herz und Nieren zu testen und sicherzustellen, dass die Plug-ins über Integrationstests verfügen, eine gute Performanz aufweisen und korrekt mit m2eclipse interoperieren. Wir wollen dieses Projekt nach der Veröffentlichung von Maven 3.0, m2eclipse 1.0 und Tycho 1.0 in Angriff nehmen.
JAXenter: Sonatype entwicklet auch das m2eclipse-Plug-in, das aktuell in Version 0.10.0 vorliegt. Welche neuen Features wurden hier integriert? Was kann man für die bevorstehende Version 1.0 erwarten?
Jason van Zyl: m2eclipse 0.10.0 ist fast eine komplette Neuimplementierung von 0.9.8 und verfügt deshalb über viele Änderungen und Verbesserungen. Der wichtigste Punkt ist, dass wir die m2eclipse-Codebasis mit der Maven-3.x-Codebasis synchronisiert haben. Wenn wir also Fixes in m2eclipse vornehmen müssen, die aus Problemen mit Maven resultieren, ist es nur eine Frage von Stunden, bis wir den Bugfix im System verankert und einen neuen m2eclipse-Build produziert haben. Im letzten Jahr gab es mehrere hundert Bugfixes für Maven und m2eclipse. Mit dem Erreichen von Maven 3.0 und m2eclipse 1.0 haben wir wahrscheinlich nahezu 8000 Arbeitsstunden in Maven und m2eclipse investiert.
Die bessere Performanz wird das erste sein, was den Anwendern auffallen wird. Selbst in einem Standard-Maven-Projekt laufen die allgemeinen Operationen schneller. Und wenn man das neue inkrementelle Maven-Plug-in-API und das konfigurierbare Lifecycle Mapping nutzt, erhält man ein echtes inkrementelles Verhalten mit Maven innerhalb Eclipse.
Die neuen inkrementellen Maven Plug-in APIs erlauben es Eclipse, sehr präzise Informationen nach Maven zurückzugeben. Zum Beispiel wird Eclipse nicht mehr den ganzen Maven-Lebenszyklus auslösen, wenn man eine einzige Ressource ändert, die gefiltert werden muss, sondern nur die Information über die geänderte Datei kommunizieren und Mavens Ressource-Plug-in ausführen, um nur diese geänderte Datei zu bearbeiten.
Das konfigurierbare Lifecycle Mapping erlaubt es m2eclipse, innerhalb von Eclipse, einen Großteil der Maven-Ausführungen zu vermeiden. Man kann frei wählen, welche Plug-ins als Teil des Builds innerhalb von Eclipse ausgeführt werden sollen. Dies führt dazu, dass man mit ein wenig Feintuning seines Projektes zu extrem schnellen Ergebnissen kommt. Wir möchten diese Feinabstimmung in der Version 1.0 noch weiter vereinfachen, obwohl sie auch heute schon relativ problemlos ist.
Wir haben auch eine verbesserte Integration mit Nexus umgesetzt, sodass man den Inhalt der Repositories innerhalb von Eclipse durchsuchen kann. Und wir haben die Konfiguration von Repository-Indexen vereinfacht, indem wir sie automatisch auf Basis von Repositories konfigurieren, die in der settings.xml-Datei definiert wurden.
