Lohnt sich Maven (noch) nicht für den EAR-Einsatz?

Question

Ich bin gerade dabei, mehrere J2EE-Projekte von Ant auf Maven2 zu portieren. Alle diese Projekte enthalten 1 EJB und 1 Webmodul und verwenden die empfohlene "skinny" EAR-Paketierungsmethode. Das bedeutet, dass die JARs, von denen die EJB- und/oder Web-Module abhängen, einfach in den Root der EAR gelegt werden. Sowohl EJB- als auch Webmodule haben Class-Path-Einträge in ihren jeweiligen Manifesten, um auf die spezifischen JARs zu verweisen, und der Class-Path des Webmoduls verweist auch auf das EJB-Jar.

Ich war entsetzt (ist das zu stark? :)), als ich feststellte, dass Maven dies nicht sehr gut unterstützt. Ich habe die offizielle Seite zur Handhabung von Skinny WARs gelesen, aber das bedeutete, dass ich die WAR-Abhängigkeiten im EAR pom duplizieren musste und, noch schlimmer, auch die transitiven Abhängigkeiten. Es scheint sinnlos zu sein, Maven zu übernehmen, wenn man Abhängigkeiten überall manuell handhaben muss!

Ich fing dann an zu googeln und fand eine Vielzahl von Workarounds - offensichtlich bin ich nicht der erste, der (a) ein Skinny EAR machen will und (b) den von Maven vorgeschlagenen Ansatz (der selbst ein Workaround ist) nicht mag.

Ich habe einige dieser Ansätze ausprobiert, aber keiner von ihnen hat bei mir funktioniert. Ich fand auch einige Probleme, die wie Maven-Fehler aussahen, z.B. schließt die WAR-Plugin-Direktive 'packagingExcludes' nur die direkten Abhängigkeiten aus, nicht die transitiven! Nicht sehr vertrauenserweckend. Ich habe ein JIRA-Problem für dieses spezielle Problem gefunden, aber es ist noch offen.

Ich habe dann festgestellt, dass mein Kommandozeilen-Maven 2.2.1 sich anders verhält als mein in m2eclipse eingebettetes Maven (Embedder v. 3.0). Unsere Entwickler möchten Maven auf jeden Fall von Eclipse aus steuern, daher war es keine Option, sich auf die neueste Befehlszeilenversion zu verlassen.

Meine Frage lautet also: Lohnt es sich jetzt und in absehbarer Zukunft, auf Maven zu migrieren, wenn wir unsere gesamte Entwicklung in Eclipse durchführen und hauptsächlich an schlanken EAR-Projekten arbeiten? Gibt es irgendetwas in der Zukunft von Maven, das den Umgang mit EARs in einer robusteren und integrierten Weise ermöglicht?

Answer 1

Meine Frage lautet also: Im Moment und in absehbarer Zeit und in absehbarer Zukunft, lohnt es sich auf Maven zu migrieren, wenn wir unsere gesamte Entwicklung in Eclipse machen, und wenn wir hauptsächlich an schlanken EAR-Projekten arbeiten? Ist gibt es irgendetwas in der Zukunft von Maven, das EARs auf eine robustere und integrierte Weise robuste und integrierte Art und Weise?

Kurze Geschichte: Nein, nicht solange M2Eclipse noch nicht funktioniert.

Lange Geschichte:

Derzeit würde ich davon abraten, zumindest in Eclipse. Zum Zeitpunkt der Erstellung dieses Artikels hatte und hat das M2Eclipse Plugin einen sehr unangenehmen Fehler, bei dem es seine eigene Version der application.xml Deskriptordatei generiert, anstatt diejenige zu verwenden, die Maven sonst erstellen würde.

Leider ist diese benutzerdefinierte application.xml schlichtweg falsch: Sie ignoriert finalNames, hat ein scheinbar fest einkodiertes "lib/"-Präfix und weist EJB-JARs aus irgendeinem Grund die Erweiterung ".ejb" zu. Noch schlimmer ist, dass man sie nicht entfernen kann, um sie durch die Version von Maven zu ersetzen, da sie von M2Eclipse ständig neu generiert wird.

Maven generiert die Datei application.xml nur, wenn sie nicht bereits vorhanden ist. Da die von WTP/M2Eclipse generierte application.xml ständig neu generiert wird, hat die Maven application.xml keine Chance.

Es gibt jedoch einen Workaround für dieses Problem: Sie können Maven anweisen, die application.xml während des Packens zu ignorieren, so dass es denkt application.xml nicht vorhanden ist. In diesem Fall wird trotzdem eine eigene Version erzeugt. Auf diese Weise würde die falsch erzeugte Datei application.xml keine Rolle spielen. Als Hinweis für die Zukunft:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ear-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <version>5</version>
        <earSourceExcludes>**/application.xml</earSourceExcludes>
        <generateApplicationXml>true</generateApplicationXml>
    </configuration>
</plugin>

Ein großes Problem ist jedoch, dass das Ant-Skript, das für das Deployment in GlassFish in Eclipse verwendet wird, eine eigene EAR für das Deployment erzeugt und dabei die von M2Eclipse erzeugte application.xml verwendet. Das bedeutet, dass die von ihm erzeugten EARs immer falsch sein werden, solange das M2Eclipse-Plugin nicht funktioniert. Es gibt dazu Fehlerberichte im codehaus JIRA, auf die ich im Moment aber nicht zugreifen kann.

YMMV für andere Anwendungsserver, aber seien Sie darauf vorbereitet, dass Sie viel mit application.xml herumfummeln müssen.

Answer 2

Leider ist diese benutzerdefinierte application.xml schlichtweg falsch: Sie ignoriert finalNames, hat ein scheinbar fest einkodiertes "lib/"-Präfix und weist EJB-JARs aus irgendeinem Grund die Erweiterung ".ejb" zu. Noch schlimmer ist, dass man sie nicht entfernen kann, um sie durch die Version von Maven zu ersetzen, da sie von M2Eclipse ständig neu generiert wird.

Sind Sie wirklich sicher, dass m2eclipse dafür verantwortlich ist? Ich verwende die JBoss Tools 3.1, die die m2eclipse-Integration enthalten, und habe genau das Problem, das Sie beschreiben. Ich verstehe jedoch nicht, warum sich m2eclipse überhaupt für die Quelldatei application.xml interessieren sollte.

Mein Verdacht ist, dass die JBoss Tools Informationen in die application.xml einspeisen. Bitte beweisen Sie, dass ich falsch liege. Ich würde m2eclipse nicht mehr verwenden, wenn es irgendetwas ändern würde, das nicht unter /target steht.

//GG

Answer 3

Ich war entsetzt (ist das zu stark? :)), als ich feststellte, dass Maven dies nicht sehr gut unterstützt (...)

In der Tat, Maven unterstützt keine magere WARs (siehe auch die Die Lösung des Problems der Skinny Wars Wikiseite) sehr gut, weil dies einfach nicht von Anfang an geplant war und Maven von fetten WARs ausgeht. Der Weg zur Erstellung von Skinny WARs und Skinny EARs ist also in der Tat eher ein Workarounds, der auf bestehenden Plugins aufbaut. Und, ja, dies ist fehleranfällig.

(...) Ich habe dann festgestellt, dass mein Kommandozeilen-Maven 2.2.1 sich anders verhält als mein in m2eclipse eingebettetes Maven (Embedder v. 3.0).

Beachten Sie, dass Sie m2eclipse so konfigurieren können, dass es ein externes Maven anstelle des eingebetteten Maven verwendet. Das ist genau das, was ich mache, ich möchte genau die gleiche Version, die die CI-Engine verwendet.

Meine Frage lautet also: Lohnt es sich jetzt und in absehbarer Zukunft, auf Maven zu migrieren, wenn wir unsere gesamte Entwicklung in Eclipse durchführen und hauptsächlich an schlanken EAR-Projekten arbeiten?

Mein Rat ist einfach: Wenn Maven nicht die Art und Weise unterstützt Sie Software entwickeln wollen (legitim oder nicht, das ist nicht die Frage), dann benutzen Sie sie nicht.