Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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?
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 :noe: .
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.
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:
Code:
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;
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).
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 :bahnhof: .
Woran kann das wohl liegen? Muss ich Spring als Plugin installieren oder weshalb umgeht die maven hier so gekonnt?