Maven und Eclipse Plug-in Unit Tests

[Kessi]

Hi zusammen

Vor zwei Wochen haben wir ein neues Eclipse Plug-in-Projekt mit Maven als Build-System begonnen. Der Build soll zusätzlich via Hudson Continuous Integration auf dem Build-Server durchgeführt werden. Da Hudson Maven bereits von Haus aus unterstützt, hat soweit alles rebungslos funktioniert. Nun geht es jedoch darum, die Eclipse Unit Tests, welche sich von Eclipse aus ja über "Run as..." -> "Eclipse Plug-in Test" ausführen lassen, ebenfalls von Hudson durchführen zu lassen.

Gibt es dazu ein passendes Maven Plug-in oder wie lässt sich dies am besten bewerkstelligen?

Besten Dank für jeden Tipp und beste Grüsse
Kessi

[maki]

Das Maven Surefire Plugin sollle deine Tests doch automatisch ausführen.

[kama]

Hi,

auch bei einem Eclipse-Plugin ?

EDIT:
Also wenn ich das hier richtig verstehe: Wäre das was gesucht ist...
Eclipse Corner Article: Building Eclipse Plugins with Maven 2

MfG
Karl Heinz Marbaise

[maki]

Die Kombination Maven2-Ant-PDE um ein RCP zu bauen finde ich sehr gruselig...

[Kessi]

Genau, es geht mir um die spezifischen Eclipse Plug-in Unit Tests. Der Artikel adressiert genau dieses Problem, ist allerdings 4 Jahre alt. Die scheinen ein eigenes Mojo für diesen Zweck programmiert zu haben - was ja top wäre - aber leider sind die Referenzen outdated. So lande ich beim Aufruf von Mojos z.B. auf einer IBM Webseite .

[Kessi]

Zitat: maki

	Die Kombination Maven2-Ant-PDE um ein RCP zu bauen finde ich sehr gruselig...

Bin für Gegenvorschläge offen . Was das Bauen allein angeht, hat es so bequem geklappt wie noch nie zuvor - besonders, was die Integration in Hudson angeht.

[Wildcard]

Du kannst extrem einfach PlugIn Unit Tests ausführen (und auch builden) mit Eclipse Buckminster.
Es gibt auch ein Hudson Plugin dafür:
Buckminster PlugIn - hudson - Hudson Wiki

Für einen Unit Test brauchst du nur eine Eclipse Launch Config für die Unit Test die du in etwa so aufrufst:
buckminster junit -l path/to/launchconfig.launch -o /path/to/junit/output/report
Alles funktioniert dann genaus wie wenn du die Tests von Eclipse aus aufrufst.

[Kessi]

Zitat: Wildcard

	Du kannst extrem einfach PlugIn Unit Tests ausführen (und auch builden) mit Eclipse Buckminster. Es gibt auch ein Hudson Plugin dafür: Buckminster PlugIn - hudson - Hudson Wiki Für einen Unit Test brauchst du nur eine Eclipse Launch Config für die Unit Test die du in etwa so aufrufst: buckminster junit -l path/to/launchconfig.launch -o /path/to/junit/output/report Alles funktioniert dann genaus wie wenn du die Tests von Eclipse aus aufrufst.

Hm, dem Buckminster wollte ich diese Woche einmal eine Chance geben, allerdings ist das Plugin, das ich entwickle, für CDT 6.0 und benötigt deshalb Eclipse 3.6. Für diese Eclipse Version scheint Buckminster etwas buggy, nebst endlosen NullPointerExceptions erhalte ich diese Meldung beim Versuch, das Beispielprojekt auszuchecken:

ERROR   [0001] : java.lang.NoSuchMethodError: org.eclipse.buckminster.jdt.ClasspathReader.decodeClasspath(Ljava/lang/String;Ljava/util/Map;)[[Lorg/eclipse/jdt/core/IClasspathEntry;
Errors and Warnings
E [0001] : java.lang.NoSuchMethodError: org.eclipse.buckminster.jdt.ClasspathReader.decodeClasspath(Ljava/lang/String;Ljava/util/Map;)[[Lorg/eclipse/jdt/core/IClasspathEntry;: org.eclipse.buckminster.jdt.ClasspathReader.decodeClasspath(Ljava/lang/String;Ljava/util/Map;)[[Lorg/eclipse/jdt/core/IClasspathEntry;

[Wildcard]

Zitat: Kessi

	Hm, dem Buckminster wollte ich diese Woche einmal eine Chance geben, allerdings ist das Plugin, das ich entwickle, für CDT 6.0 und benötigt deshalb Eclipse 3.6. Für diese Eclipse Version scheint Buckminster etwas buggy, nebst endlosen NullPointerExceptions erhalte ich diese Meldung beim Versuch, das Beispielprojekt auszuchecken:

Eclipse 3.6 sind nunmal Milestones. Die funktionieren mal und mal nicht.
Du hast da aber etwas falsch verstanden. Nur weil du für CDT 6.0 entwickelst bedeutet nicht das du Buckminster 3.6 brauchst. Du brauchst ja auch kein Eclipse 3.6 um CDT 6.0 zu Entwickeln. In Eclipse löst man das über die Target Platform. Du entwickelst mit 3.5 gegen eine 3.6 Targetplatform und bei Buckminster funktioniert es exakt genauso.
Du kannst entweder alle 3.6/CDT Abhängigkeiten von Buckminster in den Workspace laden lassen, oder eine Target Platform verwenden (wahlweise ein Target Definition file (.target), oder ein Verzeichnis das ein plugins und ein features Verzeichnis enthält in dem die CDT Plugins liegen).

[Kessi]

Soweit eigentlich logisch, danke . Das werde ich bei Gelegenheit ausprobieren, wenn mich maven hier weiterhin im Stich lässt. Jedenfalls, nach einiger Recherche bin ich darauf gestossen, dass ich die ganze Sache vermutlich ziemlich falsch angegangen bin. Das maven-eclipse-plugin verfügt über ein <pde>-Tag, das man im POM aktivieren kann, sodass die Projekteinstellungen und das Verhalten von maven für Eclipse Plugin Entwicklung angepasst werden sollten.

Das löst automatisch auch eine ganze Reihe anderer Probleme, die ich hatte, wie z.B. die Abhängigkeiten zu den anderen Eclipse-Plugins, die ich via Repository aufgelöst hatte - die werden jetzt automatisch anhand der installierten respektive im plugin.xml referenzierten Plugins aufgelöst.

Ein weiteres, recht unscheinbares Problem stellt sich mir aber trotzdem in den Weg: Die Abhängigkeiten, die das maven-eclipse-plugin auflöst, werden wunderbar im .classpath eingetragen und verknüpft - alle ausser die Spring-Dependencies wie z.B. spring-aspects oder spring-core, obwohl deren Abhängigkeiten (wie etwa aspectjrt) mit einbezogen werden .

Woran kann das wohl liegen? Muss ich Spring als Plugin installieren oder weshalb umgeht die maven hier so gekonnt?

Danke auf jeden Fall und beste Grüsse
Kessi