Unter Eclipse/RAD CVS-Commits für ganze Projekte anzuzeigen funktioniert nicht, das Plugin CVS Change Log for Eclipse konnte man früher ganz gemütlich in ein Plugin Verzeichnis einspielen und schon hatte man die entsprechende Funktion zur Verfügung. Für RAD 8.0.1 hat das nicht funktioniert.
Glücklicherweise gibt es ein anderes Projekt mit entsprechender Update Site, wo man einfach nur eine URL unter Help/Install new Software... eintragen muß und schon hat man die Funktionalität auch im RAD wieder zur Verfügung:
Maven 3.0.3
Eclipse Java EE IDE for Web Developers Indigo Service Release 2 20120216-1857
gwt-maven-plugin 2.4.0
build-helper-plugin 1.7
m2e - Maven Integration for Eclipse 1.0.200.20111228-1245
Google Plugin for Eclipse 3.7 2.6.1v20205091048-rel-r37
Will man mit dem org.codehaus.mojo.gwt-maven-plugin Archetype ein Skeleton GWT Projekt erzeugen kann das ein ziemlicher Task sein. Irgendwie hab ich das trotzdem hinbekommen, es gibt sicher andere und wahrscheinlich auch bessere Wege, aber ich beschreibe mal wie ich vorgegangen bin.
Zuallererst: Das m2eclipse Plugin von Sonatype muß deaktiviert oder deinstalliert werden, es ist meiner Meinung nach einer der Hauptgründe warum es so schwierig ist das Ganze hinzubekommen.
Dann ein neues Maven Projekt anlegen und den Archetype gwt-maven-plugin verwenden:
Danach füge ich im pom.xml mit dem build-helper-maven-plugin den zu generierenden Code zum Sourcepath hinzu (m2eclipse ignoriert das einfach, einer der Gründe, warum es raus mußte). Beim Probelauf für diesen Blogeintrag hatte das Projekt danach trotz deaktivierten m2e eine Maven Nature (am hinzugefügten M erkenntbar). Diese habe ich einfach deaktiviert, dann muckste m2e auch wirklich nicht mehr auf (Rechter Mausklick aufs Projekt -> Maven -> Disable Maven Nature).
Dann baue ich mir einen Launcher für das externe Maven und lasse das Ganze mal mit dem Goal install laufen:
Der Lauf geht inklusive Tests durch, auch die generierten Sourcen sind eingebunden, sieht einmal sauber aus.
Nun probiere ich das Ganze auch mal mit den Mavengoals clean gwt:run laufen zu lassen und siehe da, es funkt:
Auch im Browser sieht das sauber aus:
Im Prinzip nicht viel zu tun, es hat allerdings schon seine Zeit gebraucht bis ich mich durchgerungen habe das an sich tolle m2eclipse Plugin zu deaktivieren.
Am Ende noch der Projektbaum, wie er aussieht wenn alles gut gegangen ist:
Händisches kopieren von Ressourcen aus einem allgemeinen Projekt in ein spezifisches Projekt kann sehr nervig werden, darum hab ich das mal automatisiert. Erster Task ist, das im Repository nur das jar rumliegt, das muß man sich holen und entpacken. Das kann das maven-dependency-plugin für einen erledigen:
Zu beachten ist dann noch, das die kopierten Ressourcen wahrscheinlich ins SCM reinrutschen sollen. Will man um alles wirklich sauber zu machen am Beginn des Builds die alten kopierten Files noch löschen macht man das so: Beitrag zum Löschen von Files in der clean Phase des Maven Builds
Commons Ressourcen lasse ich mir im Laufe des Mavenbuilds reinkopieren, allerdings sollte vorher ausgemistet werden, falls nämlich Ressourcen umbenannt wurden kommt es zu Doppelgleisigkeiten, die besonders bei Javascript Ressourcen sauber weh tun können.
Leider treiben sich zwischen meinen Commons auch applikationsspezifische Ressourcen herum, darum kann nicht alles einfach weggeworfen werden. Dazu zählen im besonderen auch die .cvsignore Files, die verhindern das mir meine Commons, die ja eh bei jedem Build aus dem Commons-Projekt umkopiert werden, ins CVS rutschen.
Beim Beispielprojekt handelt es sich um einen Source Code Generator, der aus einem File, das Text in einer Domain Specific Language enthält, Java Code generiert.
Soweit so gut, nun soll beim Build aus einigen Test DSL Files der Source Code erzeugt werden und gegen einige JUnit Tests gefahren werden, um zu sehen ob der generierte Code den Erwartungen entspricht.
Das Ganze war entgegen meinen ersten Befürchtungen dann dank Maven einfach, dafür gibts das exec-maven-plugin.
Hier wird die Main Methode der angegebenen Klasse ausgeführt, in meinen Fall Test Source an der richtigen Stelle erzeugt (Das ist in der Klasse festgelegt, wird hier eigentlich nur dadurch bedacht das testSourceRoot angegeben wurde, damit Maven auch sicher mitkriegt das dieser Code vor dem Test auch brav kompiliert wird). Einfacher gehts eigentlich nimmer.
Damit vom generierten Code nicht irgendwann störende Restbestände herumliegen lösche ich diese bevor neuer generiert wird mithilfe des maven-clean-plugin:
maven-clean-pluginsrc/test/java/genfalse
Das wars eigentlich.
Was etwas irritieren kann ist, daß vor dem Build immer unkompilierbarer Code herumliegt, damit die JUnit Tests kompilieren muß erst der Test Source generiert werden.
Hierbei hilfreich hat sich der Parameter maven.test.failure.ignore erwiesen, einfach auf true setzen und schon läuft der Build auch bei Test Failures zu Ende und schließt sogar mit Success ab, wenn sonst nix Störendes passiert.
Im Prinzip nicht viel zu tun, es hat allerdings schon seine Zeit gebraucht bis ich mich durchgerungen habe das an sich tolle m2eclipse Plugin zu deaktivieren.
