JAXenter: Mit dem Eclipse-Projekt IAM (früher Q4E) steht ja auch ein offizielles Eclipse-Projekt zur Integration von Maven in Eclipse zur Verfügung. Was ist der Unterschied zwischen IAM und m2eclipse? Und ist hier eine Verschmelzung geplant?
Jason van Zyl: IAM ist nicht das offizielle Projekt für die Integration von Maven in Eclipse. Sowohl m2eclipse als auch IAM befinden sich noch in der Inkubationsphase, sodass keines der Projekte den Status eines offiziellen Eclipse-Projekts hat. Es ist unwahrscheinlich, dass es hier zu einem Merger kommen wird. Die Codebasis des IAM-Projekts ist zum jetzigen Zeitpunkt ein Jahr hinter m2eclipse zurück, und es gibt keine aktiven Maven 3.x Committer im IAM-Team. Sonatype verfügt hingegen über Vollzeit-Entwickler und Angestellte, die sich um das Qualitätsmanagement von Maven 3.x und m2eclipse kümmern. Wir haben eine Menge Arbeit im Laufe des letzten Jahres investiert, um sicherzustellen, dass Maven und Eclipse gut miteinander harmonieren. M2eclipse ist der De-facto-Standard.
Man kann das auch am Community-Feedback sehen, da sich Fragen auf den User-Mailing-Listen immer auf m2eclipse beziehen. Auch Anbieter-neutraler Support für m2eclipse ist bereits zur Stelle: Genuitec, JBoss und SpringSource integrieren alle m2eclipse, aber nicht IAM. Sicherlich ist es denkbar, dass Eclipse beide Projekte aus der Inkubationsphase entlassen wird, doch nur ein einziges Projekt wird offiziellen Status erlangen und mit den Distributionen ausgeliefert werden – und es ist sehr wahrscheinlich, dass dies m2eclipse sein wird.
JAXenter: Mit Tycho habt ihr eine neue OSGi-Toolchain für Maven bereitgestellt, die potenziell den PDE-Build-Prozess von Eclipse ersetzen soll. Welche Ziele verfolgt man mit Tycho und wie ist der aktuelle Entwicklungsstand?
Jason van Zyl: Der Fokus von Tycho liegt auf der Entwicklung einer effektiven Hybrid-Lösung, die Maven– und Eclipse-basierte OSGi-Technologien für das Bauen, Veröffentlichen und Verteilen von Eclipse-Plug-ins, Update-Sites, RCP-Anwendungen und OSGi Bundles miteinander verbindet. Tycho verfolgt dabei einen "Manifest-first"-Ansatz für den Build und nutzt Eclipse Equinox, JDT und P2. Der alternative Ansatz wäre "POM-first", der z.B. im Maven Bundle Plug-in zum Einsatz kommt, das Peter Kriens BND Tool nutzt, um ein Manifest aus den Klassen nach dem Build zu generieren.
Beide Ansätze werden noch eine ganze Weile nebeneinander bestehen bleiben, sodass es ein weiteres Ziel von Tycho ist, für die Interoperabilität der Ansätze zu sorgen. Beide Ansätze produzieren Bundles, doch um Tycho zu nutzen, müssen die Bundles in einem P2 Repository verfügbar sein und über die begleitenden P2-Metadaten verfügen. Mit einem POM-first Ansatz generiert man also dynamisch die benötigten P2-Metadaten für Bundles, die nicht über solche Daten verfügen. Dies erlaubt es tatsächlich, alle verfügbaren Bundles im Maven Central Repository zu nutzen und sie innerhalb von Tycho zu verwenden.
Ich denke, dass sich eine unüberbrückbare Kluft auftun wird, wenn Werkzeuge nicht in der Lage sind, die Interoperabilität zwischen diesen beiden gebräuchlichen Entwicklungsformen zu gewährleisten. Viele Leute verwenden Maven, um Bundles zu erzeugen, und viele nutzen zum gleichen Zweck Eclipse-basierte Standard-Technologien. Wenn diese beiden Welten nicht miteinander vereint werden, wird es zu einer massiven Verdoppelung der Anstrengungen kommen. Tycho ist die Brücke zwischen diesen beiden Welten.
Wir haben Tycho außerdem in m2eclipse integriert, sodass man ein Tycho-Projekt in Eclipse als PDE-Projekt importieren kann. Wir haben auch die Option hinzugefügt, die Auflösung von POM-first Bundles im Eclipse Workspace durchzuführen. Derzeit gibt es zwei große Projekte bei Eclipse, welche Tycho für ihre Builds einsetzen: das Tigerstripe-Projekt, das von Cisco vorangetrieben wird, und das EGit-Projekt. Das EGit-Projekt ist interessant, weil es einen hybriden Ansatz verfolgt: Zunächst kommt ein POM-first Build für JGit zum Einsatz. Dann wird ein P2 Repository vom Tycho Build generiert, der vom EGit Build verwendet wird, welcher wiederum einen Manifest-first Tycho-Build nutzt.
JAXenter:Vor kurzem wurde das Projekt Polyglot Maven ins Leben gerufen. Welche Ziele verfolgt das Projekt?
Jason van Zyl: Polyglot Maven ist das Projekt, in dem wir mit Domänen-spezifischen Sprachen (DSLs) und Terse Markup Sprachen (TSLs) in Verbindung mit dem Maven-3.x-Kern experimentieren. Was derzeit schon zur Verfügung steht kann unter http://polyglot.sonatype.org eingesehen werden.
Was wir hier haben, sind Ausgangspunkte für interne DSLs für Groovy, Ruby, Scala und Clojure. Es gibt außerdem eine externe DSL, welche ich mit Xtext entwickelt habe - einem fantastischen Tool bei Eclipse.org, um Parser und Editoren für externe DSLs zu erzeugen. Wir stellen auch Unterstützung für YAML-basierende POMs bereit, unter Nutzung der exzellenten SnakeYAML-Bibliothek.
Die DSLs sollen mehr sein als nur alternative Repräsentationen der POMs. Die DSLs haben den vollen Zugang zu Mavens internen Strukturen, die hinsichtlich Integrationen und Erweiterungen komplett überarbeitet wurden. Was dies praktisch bedeutet ist, dass DSL-Implementierer Mavens Infrastruktur nutzen können und eigene Weisen der Interaktion mit Maven - oder der Erweiterung von Maven - entwickeln können.
Eine DSL könnte beispielsweise Mavens Lebenszyklus ändern, bestimmte Phasen des Zyklus neu ausgestalten, eigene Konfigurationsmechanismen erzeugen oder einen mehr prozeduralen Mechanismus für die Anwender erlauben. Ich weiß ganz ehrlich gesagt nicht, wie nützlich diese Features tatsächlich für allgemeine Anwender und insbesondere Enterprise-Anwender sind. Ich sehe aber doch nur Vorteile darin, eine tiefer greifende Nutzung der Infrastruktur von Maven zu ermöglichen.
Was mir wirklich am Herzen liegt ist die Interoperabilität auf der Ebene des Repositories und des Tooling. Dies ist der Grund dafür, warum der Code im Polyglot-Maven-Projekt liegt. Ich möchte den Anwendern auf keinen Fall vormachen, dass das Projekt schon bereit für den großflächigen Einsatz ist. Es ist zwar voll funktionsfähig, doch müssen wir uns noch einige Gedanken darüber machen, wie Projekte, die möglicherweise mit vielen DSLs konstruiert werden, noch gut funktionieren und miteinander harmonieren. Wie werden die resultierenden Metadaten aussehen, die in Maven Repositories exportiert werden? Zurzeit denken wir, dass es wahrscheinlich ein Maven 2.x POM sein wird, welches während des Deployment-Prozesses erzeugt wird.
Wie wird das Tooling für Maven DSLs aussehen? Wir hoffen, dass die DSLs viele der Maven-internen Modelle unangetastet lassen, sodass sie von m2eclipse profitieren können. Einfach nur die Infrastruktur für diese DSLs bereitzustellen, ist nicht genug; Repository-Interoperabilität und Tooling sind wichtig.
In den letzten 18 Monaten habe ich fast 2000 Leute in meinen zahlreichen Talks und Präsentationen befragt, und ungefähr fünf Prozent der Leute sind an DSLs für Maven oder anderen Repräsentationen des POM interessiert. Aber diese fünf Prozent sind sehr wichtig. Es handelt sich dabei um die kreativen Hacker, die Dinge in einem Projekt von Anfang bis Ende auf rein programmatische Art und Weise tun möchten. Sie wollen alles programmieren, inklusive den Build. Aus diesem Grund habe ich das Polyglot-Maven-Projekt ins Leben gerufen, weil ich glaube, dass diese fünf Prozent potentiell genauso viel zu Maven beitragen können als die restlichen 95 Prozent der Maven-Anwender-Basis. Die Leute, die den Polyglot Support wollen, sind hochgradig effektiv. Letztendlich kann das nur gut für Maven sein.
JAXenter: Es gibt nun ja verschiedene Build-Systeme. Welches ist Deiner Meinung nach die größte Konkurrenz für Maven? Vielleicht Gradle?
Jason van Zyl: Mavens größte Konkurrenz im Enterprise-Bereich stellen selbstgemachte Maven-artige Lösungen dar, die mit Ant entwickelt wurden. Es sind solche Systeme, die Maven in Enterprise-Konstellationen typischerweise ersetzt. Ehrlich gesagt kennen wir niemanden, der versucht, Dinge wie Gradle oder Buildr in großen Enterprise-Projekten auszuprobieren. Ich denke, es gibt einen großen Hype um einige dieser Technologien. Wir verstehen, dass Leute ständig nach neuen Lösungen suchen, aber wir sind auch davon überzeugt, dass der Raum der Enterprise Builds voller komplexer Faktoren ist, die man nicht mit vereinfachenden Lösungen in den Griff bekommt.
JAXenter: In drei Sätzen: Warum sollte man auf Maven 3 wechseln?
Jason van Zyl: Maven 3.0 wird die beste Maven-Version sein, die jemals entwickelt wurde. Wir tun alles in unserer Macht stehende dafür, um Maven 3.0 rückwärtskompatibel zu halten, und wir haben tausende von Arbeitstunden in Testprozesse und Performance-Optimierungen investiert. Maven 3.0 ist die Zukunft von Maven und ein Schritt vorwärts für alle Anwender, die neue Technologien wie m2eclipse, Tycho, Maven Shell, Polyglot Maven und Nexus nutzen wollen.
