Eclipse erweitern ist nicht schwer, die richtige Plugin-Auswahl dagegen sehr.

Ich arbeite jetzt schon einige Zeit mit der Eclipse 3.2 WTP 1.5 und bin recht zufrieden. Selbst auf älteren Rechnern kommt sie noch ganz gut aus dem Quark und läuft stabil (wenn man die richtigen Plugins an Board hat).

Da ich schon seit einiger Zeit nach einer Integrationsmöglichkeit für den OC4J im Kontext zu Maven 2.x suche, probiere ich immer mal wieder etwas aus. Von der Theorie ist es ganz einfach. Aber die Implementierungen der Plugins lassen doch einiges zu Wünschen übrig.

Grundsätzlich kann die WTP 1.5 Application Server integrieren. Auch für OC4J ist was dabei. Nur eben für Projekte, die direkt in Eclipse erzeugt werden. Wobei meine Kurztests auch noch so ihre Macken zeigten. Wenn man aber grundsätzlich mit Maven 2.x Build-Prozeß arbeitet, sieht die Sache schon anders aus. Sicher kann man mit

mvn eclipse:eclipse

aus jedem übersetzbaren Projekt auch eine Version zaubern, die sich in Eclipse laden läßt. Aber ohne sinnvolle Maven 2 Unterstützung in Eclipse geht’s dann doch nur halbautomatisch.

Es wird seit einiger Zeit ein Maven 2.x-Plugin angeboten. Aber leider taugt das zusammen mit Eclipse 3.2 bzw. der WTP 1.5 nicht die Bohne. Schon beim Anzeigen von Dialogen wirft es Exceptions. Letztens konnte ich selbst Standard XML-Dateien mal öffnen, dann mal wieder nicht. Die meisten Versuche zogen eine Neuinstallation von Eclipse nach sich.

Es ist ziemlich übel, daß die automatischen Updates immer die letzte Version 0.9 anziehen. An anderer Stelle im Netz war zu lesen, daß die 0.5 noch laufen soll. Das werde ich noch mal bei Gelegenheit versuchen. Leider läßt das notwendige Update noch immer auf sich warten (und der Bugtracker wächst und wächst ;-)).

Da es an der notwendigen Maven 2.x Unterstützung für Eclipse hapert, kann auch der OC4J nur angeflanscht, aber nicht wirklich integriert betrieben werden. Ich habe einen Tools-Eintrag vorgenommen, der den Maven-Build ausführt und kann zumindestens jetzt OC4J aus der Server-Sicht starten und stoppen. Beide zeigen ihre Ausgabe im Consolen-Fenster. Der OC4J Enterprise-Manager läßt sich dann noch recht gut in einem internen Browser-Fenster nutzen. Somit kann die meiste Arbeit im Eclipse erledigt werden. Leider hat OC4J wohl Probleme mit den Zugriffen im Windows-Dateisystem, so daß er regelmäßig neu gestartet werden muß :-(.

Ganz anders sieht es da mit der SpringIDE aus. Die ist wirklich cool. Wer die applicationContext.xml zunächst in einem “normalen” XML-Fenster bearbeitet hat, wird es zu schätzen wissen, daß wichtige Abhängigkeiten zu den Bean-Implementierungen sofort geprüft werden. Das erspart so manch unnötiges Deployment, wenn man in einer “nicht-reinen Spring-Umgebung” unterwegs ist. Im Ansatz sehr gelungen ist auch die Visualisierung der Abhängigkeiten ([ref]) der Beans in der applicationContext.xml. Leider werden noch keine indirekten Abhängigkeiten (z.B. via [list]) berücksichtigt. Deshalb finden sich auch einige herrenlose Kästchen am Ende der grafischen Darstellung wieder.

Besonders gelungen finde ich auch die TestNG-Unterstützung. Das Plugin wird stets zeitgleich vom selben Autor zur Verfügung gestellt. Abgesehen von der Eleganz des Test-Frameworks, das immer noch etwas cooler auf mich wirkt als die nachgezogene JUnit+Annotations, kommt auch die Integration ansprechend daher. Wer mal schnell die Unit-Tests durchlaufen will, ohne jedesmal Maven und Surefire zu bemühen, gewöhnt sich schnell daran.

Tja, soweit ich Zeit hatte, Plugins zu testen, sind SpringIDE und TestNG derzeit meine Favoriten. Fehlen tut mir natürlich noch eine anständige Maven 2.x Unterstützung.

Ich bin letzte Tage auf eine interessante Liste gestoßen, die ich wohl noch mal etwas genauer untersuchen werde:

Java-Tutor (der mit “Java ist auch eine Insel”)