Am Ende dieses Tutorials ist ein deploytes Java EE 6 Projekt mit JSF 2, CDI, EJB 3.1 und JPA 2 auf dem JBoss 6 vorhanden und aufrufbar. Dabei wird die Eclipse WTP Untestützung funktionieren, der JBoss direkt aus Eclipse heraus gestartet und Maven als Build Tool verwendet werden.

Kleine Anmerkung vorab: Nicht von der Länge des Tutorials abschrecken lassen – es sind eigentlich nur sehr viele Bilder. Kennt man die Technologien und Tools dauert das Erstellen dieses Projekts nur wenige Minuten.

Aufbau des Tutorials:

• Herunterladen der notwendigen Software und Tools
  • Eclipse herunterladen
  • JBoss AS herunterladen
  • Maven herunterladen
• Eclipse konfigurieren
  • JBoss Tools
  • JBoss 6 AS Server Runtime
  • Maven
  • Maven Extras – WTP
• Java EE 6 Projekt erstellen
  • Projekt mit Maven generieren
  • JSF Capabilities hinzufügen
  • CDI Support hinzufügen
  • Projekt auf den JBoss deployen
• Wie geht es weiter?

Herunterladen und Installieren aller benötigten Software und Tools

Eclipse Helios für Java EE Entwicklung herunterladen

Als erstes wird Eclipse in der Java EE Entwickler Version von eclipse.org heruntergeladen.

Das heruntergeladene Archiv am Ort deiner Wahl entpacken – z.B. einfach im Laufwerk C.

JBoss AS 6

In diesem Tutorial wird der JBoss 6 Final als Application Server verwendet denn dieser implementiert die Java EE Web Profile Spezifikation. Der JBoss AS kann unter jboss.org heruntergeladen werden.

Nach dem Herunterladen das Archiv auch wieder am Ort deiner Wahl entpacken – kann z.B. auch wieder das Laufwerk C: sein.

Maven 3

Um den Projektstart zu vereinfachen und alle Abhängigkeiten automatisch zu beziehen wird Maven 3 verwendet. Später wird auch das Grundgerüst unseres ersten Java EE Hello World Projekts mit Maven generiert. Somit muss Maven 3 “installiert” werden. Maven kann von http://maven.apache.org heruntergeladen werden:

Maven muss auch wieder an einem Ort deiner Wahl entpackt und anschließend das maven/bin Verzeichnis im Pfad (Umgebungsvariable PATH) angegeben werden damit der Befehl mvn in der Kommandozeile gefunden wird.

Installationsanleitung für Linux (Ubunutu 11.04) anzeigen.

Eclipse konfigurieren

Zuvor wurde bereits die die aktuelle Eclipse Helios (3.6) Java EE IDE heruntergeladen sowie entpackt und diese sollte spätestens jetzt gestartet werden. Beim ersten Start von Eclipse wir gefragt wo man seinen Workspace hinlegen möchte. Wieder einfach einen Ort deiner Wahl angeben und das Häckchen bei “nicht noch einmal fragen” setzen.

Für das Java EE Projekt mit Maven Unterstützung werden zum einen die JBoss Tools und zum anderen das Maven2Eclipse Plugin benötigt. Dabei spielen die JBoss Tools bei der Entwicklung von Java EE Projekten unter Eclipse generell eine sehr wichtige Rollen denn sie decken die meisten Themen wie z.B. JSF 2.0, CDI oder JPA sehr gut ab.

JBoss Tools Eclipse Plugin

Die aktuelle Version 3.2 der JBoss Tools gibt es dabei noch gar nicht so lange denn sie wurde erst Mitte Februar Final. Die JBoss Tools werden am einfachsten über die offizielle Update Seite installiert: http://download.jboss.org/jbosstools/updates/stable/helios/
Dazu in Eclipse im “Hauptmenü->Help->Install New Software…” klicken. Im aufkommenden Dialog den Button “Add” klicken um die Update Seite hinzuzufügen:

Diesen Dialog mit dem Button “Add” beenden und anschließend wird man erst einmal durch den Schriftzug “Pending…” sehen, dass das Repository geladen wird. Das kann unter Umständen eine ganze Weile dauern:

Sobald das Repository geladen wurde ist eine Liste mit allen möglichen Gruppen zu sehen. Die bisher bekanntesten Tools wie z.B. die JBoss AS Tools, Seam Tools oder Hibernate Tools befinden sich in der Gruppe “Web und Java EE Development”. Man könnte jetzt alles durchgehen und nur die benötigten Tools selektieren aber der Einfachheit halber selektiere ich “All JBoss Tools 3.2.0″:

Anschließend den Button “Next” klicken. Jetzt werden die Abhängigkeiten geprüft und das dauert auch wieder eine kleine Ewigkeit.
Sobald die Prüfung fertig ist sieht man noch einmal die Liste aller Tools die installiert werden sollen. In der Liste taucht sicherlich das ein oder andere Tool auf welches nicht wirklich benötigt wird aber es schadet auch nicht. Den Dialog mit “Next” beenden.
Auf dem letzten Dialog die Lizensvereinbarungen akzeptieren und den Button “Finish” klicken. Anschließend beginnt die Installation der JBoss Tools:

Die Installation verlangt einen Eclipse Neustart.

JBoss Server Runtime konfigurieren

Das spätere Projekt soll direkt von Eclipse heraus in den JBoss Server deployt werden. Dazu muss der JBoss als Server Runtime Environment in Eclipse konfiguriert werden. Um das zu tun die Eclipse Eigenschaften aufrufen “Hauptmenü->Window->Preferences” und die Optionen mit dem Wort “Server” filtern. Unter dem Punkt “Runtime Environments” wird der JBoss Server als Runtime hinzugefügt:

Den Button “Add” klicken und im nächsten Dialog unter “JBoss Community” den “JBoss 6.0 Runtime” auszuwählen. Der Einfachheit halber direkt die Checkbox “Create a new local server” selektieren – das erspart die anschließende Konfiguration einer Server Instanz:

Mit dem Button “Next” in den letzten Dialog wechseln und dort das Verzeichnis auswählen indem der JBoss entpackt wurde (z.B. C:\jboss-6.0.0). Als JRE muss das in Eclipse konfigurierte JDK ausgewählt werden. Unter Configuration default auswählen. Den Wizzard mit dem Button “Finish” beenden:

Nun ist die konfigurierte Server Runtime aufgelistet und kann verwendet werden:

In dem Server-Panel ist auch die lokale Instanz zu sehen:

Als letzte Konfiguration der eingebetteten JBoss Server Instanz wird jetzt noch das Deployment-Verzeichnis geändert. Per default wird die deployte Anwendung im lokalen Workspace in einen versteckten Ordner deployt. Ich mag es lieber wenn meine Anwendung auch mit direkt in den JBoss deploy Ordner deployt wird und dann auch dort zu finden ist.
Um das Deployment-Verzeichnis zu ändern mit einem Doppelklick auf die JBoss Server Instanz die Konfiguration öffnen. Anschließend am unterem Ende des Fensters auf den Tab “Deployment” klicken. Auf der Deployment Seite nun die Einstellung “Use JBoss deploy folder” selektieren und die Einstellungen speichern:

Nun kann der Server endlich durch klick auf den grünen Pfeil gestartet werden – er sollte ohne Probleme hochfahren. In der Console sollte am Ende die Startdauer zu sehen sein:

Im Browser lässt sich der JBoss auch bereits aufrufen:

Wunderbar – der Server läuft =).

Maven Unterstützung in Eclipse

Um Maven direkt aus Eclipse heraus verwenden zu können benötigt man das m2eclipse Plugin von Sonatype. Die Plugin Installation wird wieder über das “Hauptmenü->Help->Install New Software…” gestartet. In meiner Helios Version war die Update URL für das m2eclipse Plugin bereits konfiguriert. Ansonsten einfach folgende Update URL hinzufügen: http://m2eclipse.sonatype.org/sites/m2e
Ist dieses Update URL selektiert wird das Repository geladen. In diesem Fall ist nur ein Plugin selektierbar und das muss natürlich selektiert werden:

Den Dialog mit “Next” weiterführen.
Anschließend kommen wieder die Installationsdetails und die Lizensbedingungen. Den Wizzard mit “Finish” beenden und abwarten bis man aufgefordert wird Eclipse neu zu starten.
Es kann sein, dass nach dem Neustart das Maven Plugin meldet, dass Eclipse mit einem JDK gestartet werden muss:

In diesem Fall die Datei eclipse.ini öffnen (liegt direkt neben der Datei eclipse.exe) und unter dem Ausdruck openFile und oberhalb von -vmargs den Verweis auf die JDK angeben:

Mehr zu der Datei eclipse.ini findest du auch im Eclipse Wiki.

Nach dem Neustart kann in den Eclipse Preferences (Hauptmenü->Window->Preferences) die Maven Einstellungen konfigurieren. Darunter auch welches Maven verwendet werden soll. Das Plugin bringt eine Embedded-Version mit. In Eclipse reicht diese embedded Version eigentlich aus. Es empfiehlt sich aber die eigene Installation zu verwenden, so dass man auf der Kommandozeile die gleiche Maven Version verwendet wie in Eclipse. Dazu in “Maven->Installations” mit dem Button Add die eigene Installation hinzufügen:

Nachdem das Maven Plugin installiert wurde und man evtl. die Maven Installation angepasst hat dauert es einen Moment bis Maven seinen Index aktualisiert hat. Sofern das Maven Index Update noch läuft sieht man dies in dem Progress Panel:

Maven Extras – m2eclipse-extras

Es fehlt noch das Maven Integration for Eclipse WTP Plugin um mit Maven mit dem Eclipse Web Tools Project zu verbinden. Dazu noch einmal im Hauptmenü “Help->Install New Software..2 klicken und die Update URL auswählen oder hinzufügen: http://m2eclipse.sonatype.org/sites/m2e-extras

Anschließend den Wizzard wieder wie gewohnt durchgehen und das Plugin installieren.

Das erste Java EE 6 Projekt

Nun ist Eclipse konfiguriert und vorbereitet – es ist Zeit für das erste Java EE 6 Projekt mit Eclipse WTP und Maven Unterstützung.

Projekt mit Maven generieren

Um ein neues Projekt anzulegen im Hauptmenü “File->New->Other” klicken und im geöffneten Startfenster des Wizzards “Maven Project” auswählen:

Mit den Button “Next” weiter. Im zweiten Dialog “Select Project Name and Location” die Voreinstellung “Use default Workspace Location” selektiert lassen und Button “Next” klicken.
Im folgenden Dialog “Select an Archetype” nach “knappsack” filtern und ee6-sandbox-archetype auswählen. Falls dieser Archetype nicht verfügbar ist kann es sein, dass der Maven Index Update noch nicht vollständig durchlaufen ist – in diesem Fall sieht man in Eclipse unten rechts im Progress View, dass ein Prozess läuft und es hilft nur warten..
Die “knappsack” Archetypes wurden von Andy Gipson erstellt und ermöglichen einen sehr einfachen Start in das Projekt.
Wer ein Beispielprojekt mit einem vollständigem CRUD Beispiel haben möchte sollte das Archetype jee6-sandbox-demo-archetype verwenden.

Nach dem Selektieren des Archetypes den Dialog mit “Next” verlassen.

Auf der nächsten Seite müssen jetzt die Archetype Parameter gesetzt werden. Das ist zum Einen die Group Id und zum Anderen die Artifact Id. In die Group id kommt der übergeordnete Name der Package Struktur und als Artifact Id wird der Projektname gewählt:

Mit dem Button “Finish” den Wizzard beenden. Das Projekt wird nun generiert und das kann einen Moment dauern:

Nun ist das Projekt erstellt und man kann sich die Java, xhtml und Konfigurationsdateien ansehen die durch den gewählten Maven Archetype generiert wurden:

Diese generierten Java und xhtml Dateien sollen den Einstieg in JSF 2, CDI und JPA 2 vereinfachen.

Konfiguration in web.xml auf Servlet 3.0 umstellen

Der ausgewählte Maven Archetype hat in der web.xml als Servlet Spezifikationsversion 2.5 konfiguriert aber wir wollen 3.0 verwenden. Deswegen die web.xml Datei öffen: ALT-Shift-R -> web.xml oder im Verzeichnis src/main/webapp/WEB-INF. In dieser Datei steht auch schon als Kommentar der Hinweis, dass man für den JBoss Servlet Version 3 verwenden soll. Dazu die Zeile 10 löschen und die oberen Zeilen mit version=”3.0″ verwenden. Mein web-app Element sieht wie folgt aus:

JSF Capabilities dem Projekt hinzufügen

Öffnet man eine .xhtml Seite so öffnet sich der Visuell Editor von den JBoss Tools. Allerdings erscheint eine Fehlermeldung, dass die JSF Capabilities / JSF Unterstützung für dieses Projekt noch nicht konfiguriert ist:

Entweder in dieser Fehlermeldung direkt auf den Button “Add JSF Capabilities” klicken oder mit der rechten Maustaste auf das Projekt und aus dem Kontextmenü “Configure->Add JSF Capabilities” klicken. In beiden Varienten öffnet sich ein Wizzard mit dem ersten Dialog “Project Location”. Der vorgegebene Pfad für die web.xml Datei sollte eigentlich stimmen:

Mit den Button “Next” auf den nächsten Dialog “Project Folders” wechseln. Die vorgegebenen Pfade sollten auch hier stimmen. Die Checkbox “Add Libraries” darf nicht selektiert werden denn sonst kommt es später zu Fehlern.
Als Servlet Version muss 3.0, wie zuvor bereits in der web.xml abgeändert, ausgewählt werden.
Der Haken bei der Checkbox für “Target Server” bewirkt, dass dieses Projekt direkt dem konfigurierten JBoss hinzugefügt und mit deployt wird:

Den Wizzard mit dem Button “Finish” beenden. Man wird anschließend gefragt ob man in die Web Developer Perspektive wechseln möchte. Je nach Geschmack kann man sich die Web Developer Perspektive anschauen und verwenden oder wieder in die Java EE Perspektive wechseln.

Nun sollten sich alle .xhtml Seiten ohne Warnung im Visual Editor öffnen lassen und auch Autocomplete für JSF Tags möglich sein:

CDI (Context and Dependency Injection) Unterstützung dem Projekt hinzufügen

Als letztes müssen noch die CDI Unterstützung konfiguriert werden. Man merkt es daran, dass in der .xhtml Seite noch kein Autocomplete für die EL (Expression Language) zulässt. Wenn man z.B. in der home.xhtml den Cursor in die Expression #{demoCourseList} in Zeile 11 setzt und F3 drückt sollte die entsprechende Producer Methode der CDI Bean springen:

Die CDI Unterstützung wird genauso hinzugefügt wie die JSF Capabilites im Abschnitt zuvor. Im Kontextmenü des Projektes (rechte Maustaste auf den obersten Knoten des Projekts) Configure->Add CDI (Context and Dependency Injection) support.. klicken. Im geöffneten CDI Preferences Dialog die Checkbox selektiert lassen und den Button “Apply” drücken. Anschließend den Preferences Dialog mit dem Button “OK” wieder verlassen:

Nun den gleichen Versuch wie vorher schon in der home.xhtml machen und mit dem Cursor auf die Expression #{demoCourseList} in Zeile 11 setzen und F3 drücken. Nun öffnet sich der Java Editor genau an der richtigen Methode mit dem dazugehörigem CDI Producer:

Außerdem funktioniert nun auch Autocomplete direkt in der .xhtml Seite in einer Expression:

Projekt auf den JBoss deployen

Jetzt kommt der erste Test ob das generierte Projekt sich auch deployen und im Browser anzeigen lässt. Dazu im Server Panel überprüfen ob das Projekt dem Server hinzugefügt wurde – dazu einfach den JBoss aufklappen und vergewissern ob das jee6project zu sehen ist. Falls nicht muss das Projekt noch hinzugefügt werden: “rechte Maustaste auf JBoss 6.0 Runtime Server->Add and Remove…”. Anschließend den Server starten:

In der Console erscheinen dann irgendwann die folgenden Zeilen:

Nun die deployte Anwendung im Browser unter http://localhost:8080/jee6project aufrufen:

Die Seite die dargestellt wird stammt aus dem gewählten Knappsack Maven Archetype und soll die ersten Schritte in Java EE 6 bzw. in CDI vereinfachen.
Um zu prüfen ob die WTP Unterstützung funktioniert kann man das Hot Deployment ausprobieren. Hot Deployment funktioniert auf alle Web Resourcen wie z.B. .xhmtl, .css oder Bilddateien.
Um das zu testen einfach die home.xhtml öffnen und einen Text eingeben:

Nach dem speichern die Seite im Browser aktualisieren und der Text sollte direkt angezeigt werden.

Prinzipiell ist das Tutorial an dieser Stelle zu Ende – der JBoss läuft und das Java EE 6 Projekt ist deployt. Es lohnt sich als nächstes den Code durchzusehen und zu verändern. Im folgenden Abschnitt wird noch kurz auf ein paar Dinge im Source Code rund um CDI eingegangen.

Wie geht es weiter?

An diesem Punkt angekommen solltest du ein laufendes Java EE 6 Projekt im Web Profile auf dem JBoss Application Server haben. Nun kannst du dich mit Eclipse, Maven oder Java EE 6 weiter beschäftigen.
Hast du mit Java EE 6 noch überhaupt keine Erfahrungen solltest du dir dieses Projekt genauer ansehen und dich mit den bereits verwendeten Annotationen und Aufbau vertraut machen.

Viel Spaß beim ausprobieren =).

In einem Kommentar bei dem Hinweis von Adam Bien auf dieses Quickvote verweist jemand auf die Entwicklung bei Google. Schaut man sich also diese Entwicklung bei Google innerhalb Deutschlands an so erhält man noch einen deutlicheren Vorsprung von Eclipse, der allerdings über die letzten Jahre deutlich weniger geworden ist:

Die Charts auf Google Insights for Search kann man auch einbetten, was ich doch direkt mal ausprobieren musste:

Insgesamt kann man an der Umfrage und dem Chart gut erkennen, dass Eclipse nicht mehr ganz die alleinige Herrschaft hat bzw. sie langsam verliert. Ich hatte vor Jahren mal NetBeans ausprobiert, war damals aber nicht so begeistert und bin deswegen auf Eclipse umgestiegen. Auch in meinen bisherigen Projekten wurde eigentlich ausschließlich Eclipse verwendet. Vielleicht sollte man sich aber dennoch mal wieder NetBeans anschauen. Aktuell habe ich davon gelesen, dass die JSF 2 Unterstützung darin schon sehr gut sein soll. Ich werde wohl dennoch erst einmal weiterhin ein Unterstützer von Eclipse sein =).

(via Adam Bien)

Das Problem ist, dass zu oft in Projekten herumgewurschtelt wird,
Doku Mangelware und ein Modell oftmals gar nicht oder nur aus der
Anfangsphase vorhanden ist.

Und das wird dann vom Projektleiter stolz als “agile Entwicklung”
verkauft.

Der Java Trendbarometer, bzw die Kommentare bei der Erhebung, nennt diese Entwicklung “Chaos-driven” und “pseudeagli” und hat damit wohl nicht ganz unrecht. Der Java Trendbarometer wird von der Firma expeso erhoben und zwei mal jährlich veröffentlicht und im Juli ist der aktuellste nun veröffentlicht worden.

Zurück zum agilen Vorgehen. Es wurde nach der typischen vorgehensweise im Entwicklungsprozess gefragt und wie selbstverständlich hat “agil” gewonnen:

Das Thema der Vorgehensweisen ist auch das am häufigsten und wohl konroversesten diskutierte Thema.

Nun aber ein paar interessante Grafiken rund um Java. Die Frage nach der Häufigkeit der verwendeten Java Versionen zeigt, dass JDK 1.4 doch so langsam immer weniger wird.

In der JavaEE Welt bestimmen allerdings immer noch die Altlasten bzw. die in den letzten Jahren mit J2EE erstellten Enterprise Anwendungen den verwendeten Standard. Hier ist die Migration oder Neuentwicklung deutlich teurer als das Beibehalten der funktionierenden Anwendung.

Persönlich glaube ich allerdings, dass in den nächsten Jahren die Kurve für JEE, gerade mit der JEE 6 Spezifikation, deutlich nach oben gehen wird.

Die Frage nach der Entwicklungsumgebung finde ich auch sehr interessant. So ist Eclipse deutlicher Favorit unter den IDEs. Ich hätte allerdings gedacht, dass Netbeans einen Schritt nach vorne macht aber es hat in punkte “häufig” zur letzten Erhebung sogar abgenommen.

Jetzt kommt der Chart für die Frameworks für Web-Anwendungen. Hier hat Spring immer noch die Nase vorn und das Resultiert wohl aus der allgemeinen JEE Entwicklung. Interessant ist auch, dass die Menge der Eigenentwicklungen deutlich vertreten ist. Das Ajax hier als Framework mit aufgeführt scheint mir ein wenig Fragwürdig allerdings ist schön zu erkennen, dass ohne Ajax wohl keine Web-Anwendung mehr entwickelt wird.

Im der Frage nach der Entwicklung von Rich Internet Applications (RIA) ist Ajax allerdings wieder richtig angesiedelt und im Gegensatz zur letzten Erhebung Ende letzten Jahres hat Ajax und Webstart an Häufigkeit zugenommen.

Diese sechs Charts sind nur ein kleiner Auszug aus dem Trendbarometer und zeigen die für diesen Blog wichtigsten Themen. Die hier aufgelisteten Themen können auch direkt mit dem Artikel über den letzten Trenbarometer verglichen werden.
Weitere Themen unter den Überschriften “Aktuelle Themen (SOA)”, “Open Source”, “Software-Entwicklungsprozess” und “Inovation und Weiterbildung” werden auch in dem Trendbarometer besprochen und auch sehr interessant. Der Trendbarometer kann kostenlos bei der Firma expeso kostenlos angefordert werden.

Das einleitende Zitat stammt übrigens aus dem Heise Forum zum entsprechenden Artikel über den Java Trendbarometer . Die Diskussionen in dem Form gehen von interessant bis amüsant und es lohnt sich daher einen Blick reinzuwerfen.

In dem Eclipse JEE Package muss man wie auch unter Ganymede erst das Subversive Plugin und anschließend einen Subversive Connector installieren. Man muss also zwei verschiedene Update Sites für die Installation ansprechen.

Subversive Plugin Installation

Das Subersive Plugin selbst steht unter der Eclipse Lizenz und ist somit direkt über die Eclipse Galielo Update Site http://download.eclipse.org/releases/galileo zu finden. Diese Update Site muss nicht neu hinzugefügt werden sondern ist schon im “Install new Software” Dialog (Hauptmenü->Help->Install new Software…) unter “Work with” bereits zu finden:

Wenn die Update Site ausgewählt wurde muss unter dem Punkt “Collaboration” der “Subversive SVN Team Provider (Incubation)” selektiert werden. Das ist das von Eclipse bereitgestelte Subversive Plugin:

Anschließend die Installation mit dem Button “Next” starten und den Dialog Angaben folgen.

Da noch eine weitere Installation der Subversive Connectors folgt muss Eclipse nicht dringend wie empfohlen neu gestartet werden.

Subversive Connector Installation

Nachdem das Subversive Plugin als Basis installiert wurde muss als Subversive Connector eine externe Bibliothek installiert werden. Dazu bietet Polarion wie auch schon zu Eclipse Ganymede verschiedene Connectoren an. Die benötigte Update Site URL ist http://community.polarion.com/projects/subversive/download/eclipse/2.0/galileo-site/. Diese muss im “Install new Software” Dialog (Hauptmenü->Help->Install new Software…) noch hinzugefügt werden.

Dazu die URL einfach in das “Work with” Eingabefeld kopieren und Enter drücken. Als Connectoren kann man entweder einen reinen Windows Connector (JavaHL) oder reinen Java Connector (SVNKit) verwenden. Welchen man verwenden möchte kann man selbst entscheiden. Es ist kein Problem alle angebotenen zu installieren da man diesen später noch konfigurieren kann:

Anschließend die Installation mit dem Button “Next” starten und den Dialog Angaben folgen. Eclipse nach der Installtion wie aufgefordert neu starten.

Subversive Konfiguration

Einmal installiert kann man im “Eclipse Installation Details” Dialog (Hauptmenü->Help->About Eclipse->Installation Details) die installierte Subversive Software aufgelistet sehen:

Welcher Subversive Connector verwendet werden soll kann in den Eclipse Preferences (Hauptmenü->Window->Preferences) unter Team->SVN im Reiter SVN Connector konfiguriert werden:

Einmal alles installiert und konfiguriert kann man in der SVN Perspektive nun einen SVN Repository einrichten und seine Projekte wieder mit dem SVN Repository synchronisieren.

Eclipse Galileo entspricht der Version 3.5 und bringt seinerseits auch wieder viele neue Dinge mit. Neben den bisher schon bekannten Projekte wie z.B. WebTools, Data Tools oder C/C++ Tools bringt Galileo fünf neue Projekte mit an den Start. Persönlich finde ich das Memory Analyzer Projekt (MAT) am interessantesten. Wer einen Einblick in MAT bekommen möchte sollte sich mal das dazugehörige Blog und auch das Webinar aus dem letzten Jahr ansehen.

Nebem dem MAT sind auch noch die PHP Developer Tools, eine Mylyn WikiText Unterstützung, eine Unterstützung um XSL Tooling um XSL zu bearbeiten und zu debuggen und Verbesserungen für die Business Intelligence Reporting Tools (BIRT) mit Galileo veröffentlicht worden (siehe auch Release Notes).

Das schöne an Veröffentlichungen von Eclipse und deren Plugins sind die “New and Noteworthy” Seiten auf denen die interessantesten Erneuerungen mit einem Screenshot erläutert werden. Für Eclipse Galileo ist die Seite entsprechend der vielen Erneuerungen auch wirklich lang. Im folgenden ein paar Erneuerungen die ich auf Anhieb ganz interessant fand:

• Platform – Compare Editor enhancements
  Wirklich brauchbare Erneuerungen wie Go to line oder Open Resource und Type sowie die Möglichkeit den Encoding Type auf jeder Seite des Editors neu zu setzen.
  
• Platform – Open Resource dialog allows choice of editor
  Man kann nun den Editor für die zu öffnende Datei direkt im Open Resource Dialog auswählen, falls gewünscht:
  
• Install/Update Changes
  Wie auch bei der letzten Version wurde einiges an dem Install und Update Management gearbeitet und verbessert. Um nur eine Sache herauszugreifen im folgenden der Screenshot des vereinfachten Hinzufügen neuer Update Sites:
  
• Java Editor – Constructor completion
  Der Content Assistent bietet nun die verfügbaren Konstruktoren der Klasse zur Auswahl an:
  
• Java Editor – Open Implementation hyperlink
  Ein Feature auf das wohl sämtliche Entwickler lange gewartet haben. Von einem Interface direkt in die Implementierung via Hyperlink springen sofern nur eine Implementierung vorhanden ist. Sind mehre da werden diese in der type hierarchy aufgelistet und man kann dann direkt wählen. Den Hyperlink erhält man indem man die Taste STRG gedrückt hält und mit der Maus über die Methode fährt. Der Dialog sieht dann wie folgt aus:
  
• Java Editor – Quick Fix to start Rename refactoring
  Möchte man eine Methode mit Quick Fix (Strg-1) umbennen besteht nun die Möglichkeit auch ein Refactoring über das Projekt zu starten:
  
• Java Editor – Formatter option to preserve user line breaks
  Eine der bisher sehr nervigen Details am Formatter war, dass ich meine selbstdefinierten Zeilenumbrüche nicht behalten durfte. Das soll jetzt vorbei sein:
  

  Und nach dem formatieren:

  
• Java Refactoring and Source Actions – Generate toString()
  Ein ziemlich cooles Feature ist die Unterstützung für die toString() Methode. Man erhält diesen Dialog aus dem Context Menü unter “Source->Generate toString()…” und dieser sieht wie folgt aus:
  
• Java Refactoring and Source Actions – Comparing identical values
  Wenn zwei gleiche Variablen verglichen werden wird das nun als Warning angegeben:
  
• Java Refactoring and Source Actions – Missing hashCode() method
  Der Compiler kann nun fehlende hashCode() Methoden finden auch wenn equals() schon vorhanden ist. Dieses Feature ist per Default ausgeschalten – einschalten kann man es unter “Preferences > Java > Compiler > Errors/Warnings in the Potential programming problems”.
  

Es gibt noch einige mehr Erweiterungen die man sich auf der “New and Noteworthy” Seite ansehen kann.

Neben den neuen Projekten werden natürlich auch wieder fertige Projekt Packages angeboten – darunter auch wieder das JEE Package mit den Web Tools und Data Tools:

Startet man das Eclipse Galileo JEE Package sieht man auch an der Welcome Page eine deutlichen Änderung:

Auf dieser Welcome Page sind unter anderem die sieben wichtigsten im JEE Package durch die Web Tools Platform mitgebrachten Unterstützungen aufgelistet: Web Services, Web, XML Tools, Server Tools, Java EE, JSF, JPA. Die Web Tools Platform 3.1, welche auch erst im Juni veröffentlicht wurde, hat auch einige Erneuerungen mitgebracht die unter “Eclipse Web Tools Platform 3.1 – New and Noteworthy” im Detail angesehen werden können.

Natürlich steht auch wieder das leidige Thema Plugin Update auf der Liste und diesmal haben die JBoss Tools schon ein wenig vorgearbeitet. Schon am Anfang des Monats wurde auf dem offiziellen Blog verkündet, dass man den JBoss Tools 3.1 Milestone 1 für Eclipse Galileo installieren und testen kann. Der Update Site Link für die Developer Version ist: http://download.jboss.org/jbosstools/updates/development.

Ich habe die JBoss Tools 3.1 M1 unter Eclipse Galileo installieren und auch ohne erkennbare Probleme verwenden können. In einem ersten Versuch hat das Umbennenen ohne Probleme funktioniert. Den Rename Dialog erhält man am einfachsten aus der Seam Component View heraus. Insgesamt ein wirklich sehr nützliches Feature!
In ersten Tests mit einem bestehenden Projekt lies sich insgesamt problemlos arbeiten. Im About Dialog von Eclipse werden die entsprechenden Plugins auch korrekt angezeigt:

Auch zu den JBoss Tools 3.1 M1 gibt es eine “News and Noteworthy” Seite auf der die einzelnen nennenswerten Erneuerungen zu finden sind. Ich möchte nur kurz eins hervorherben welche ich ziemlich praktisch finde und zwar ist das der “Rename Seam Component” Dialog, der verfügbar ist wenn man in einer Klasse die mit @Name annotiert ist, sich in der components.xml oder in der Seam components view befindet. Verwendet man diesen Dialog wird der Name auch in den xhtml Dateien gefunden und dort refactored:

Der Übergang von Eclipse 3.4 auf Eclipse 3.5 mit den JBoss Tools scheint also vorerst problemlos zu funktioniern (im Gegensatz zu dem Umstieg von 3.3 auf 3.4).

Somit wünsche ich viel Spass beim ausprobieren!

if(unknownObj instanceof Integer) {
  Integer myCastedIntObj = (Integer)unknownObj;
  // do sth with casted object
}

Um diesen “instance of” Code mit anschließendem Class Cast zu erstellen besteht in Eclipse die Möglichkeit einen Quickfix zu verwenden und so die Tipparbeit deutlich zu vereinfachen. Dazu einfach das Schlüsselwort instanceof anfangen zu schreiben und Strg-Space drücken. Es öffnet sich der QuickFix Panel mit Vorschlägen wobei instanceof direkt an erster Stelle steht:

Selektiert man diesen QuickFix und drückt Enter wird das Code Template im Editor erstellt um die restlichen notwendigen Angaben wie z.B. die Variable die geprüft oder die Klasse auf die gecastet werden soll. Was viele nicht wissen ist, dass wenn im Eclipse Editor ein blauer Rahmen um ein Wort steht kann man einfach mit Tab durch das Template navigieren:

Gibt man die Klasse an auf die geprüft werden soll wird sie auch direkt in der Zeile mit dem Cast eingesetzt:

Anschließend nur noch den Namen der neuen internen Variable anpassen und mit Enter den QuickFix und somit das Bearbeiten des Templates beenden. Der Cursor postiert sich nun direkt in die Zeile unter der Class cast Zeile und es kann somit direkt weitergearbeitet werden.

Man wird diesen QuickFix wahrscheinlich seltener brauchen aber wenn man ihn kennt und weiß wie sich Eclipse verhält kann man einen solchen instanceof Ausdruck binnen Sekunden und ohne große Mühe erstellen. Man sollte es also mal ausprobiert haben und wissen, dass es diese Unterstützung gibt.

Entity Bean mit JPA Annotationen	Dazugehöriges SQL Schema für diese Entity Bean

Meistens bringen die verschiedenen JPA Implementierungen eigene Tools mit. Verwendet man z.B. Hibernate kann man zum Beispiel die von Konsole Tools in Form eines ANT Tasks verwenden. Arbeitet man mit der Eclipse Ganymede IDE hat man mit dem Web Tools Subprojekt “Dali” (Dali JPA Tools) die Möglichkeit sich das DB Schema mit Hilfe eines Eclipse Dialogs generieren zu lassen. Ich habe schon mal bei der Vorstellung der JBoss Tools 3 Alpha Version darauf hingewiesen, dass das WTP Dali Projekt ab Version 3 unterstützt wird.

Nachdem ich diesen Artikel in der ausführlichen Version erstellt hatte kam mir dieser mehr doch sehr lang vor obwohl das Konfigurieren an sich relativ schnell geht. Dahier hier die wenigen Schritte in absoluter Kurzform:

• Projekt Facet “JPA Persistence” dem EJB Projekt hinzufügen (Projekt Properties)
• JPA Plattform und DB Verbindung konfigurieren (Projekt Properties)
• Im Cotextmenü auf dem EJB-Projekt “JPA-Tools->Generate DDL…” wählen
• Im DDL Generation Dialog das Zielverzeichnis, die Ausgabedatei und Hibernate Console- (konfigurierbar über die Hibernate Perspektive) oder DB-Konfiguration angeben. Dialog mit “Finish” beenden -> DDL Datei wird erstellt.

Im Folgenden wird anhand meines kleinen Java Schnipsel Projektes gezeigt wie das Datenbankschema, genauer gesagt die DDL (Data Definition Language) Datei, mit Eclipse generiert werden kann. Dieses Projekt verwendet Hibernate und somit werden aus den JBoss Tools Plugins das Hibernate Tools Eclipse Plugin benötigt. Nun sind die JBoss Tools 3.0.0 endlich offiziell Stable erschienen und da ist es an der Zeit dieses Feature mal auszuprobieren.

Im ersten Schritt sollte überprüft werden ob die Hibernate Tools installiert sind. Aus den JBoss Tools Eclipse Plugins wird für das Generieren der DDL Datei die Hibernate Tools benötigt. Für eine Installationsanleitung der JBoss Tools siehe hier.

Mein Beispielprojekt ist in der für Eclipse normalen JEE Projektstruktur erstellt worden (mit dem Seam Web Project Wizzard):

Hat man eine solche Projektstruktur muss man nun das JPA Project Facet hinzufügen. Dazu auf dem EJB Projekt aus dem Context Menü (recht Maustaste) “Properties” aufrufen. Im Properties Dialog “Project Facets” selektieren und dort das Facet “Java Persistence” auswählen:

Wenn das Facet “Java Persistence” selektiert wurde erscheint unten im gelben Hintergrund der Hinweis, dass weitere Konfigurationsmöglichkeiten bestehen (“Further configuration available”). Am einfachsten ist es diese Konfiguration direkt auszuwählen. Hat man die Einstellung mit “Apply” bestätigt einfach das Facet noch einmal deslektieren, Apply drücken und das Facet wieder selektieren.
In dem Dialog “Modify Facet Project -> JPA Facet” muss nun die verwendete JPA Platform und die DB Verbindung konfiguriert werden. Ich verwende Hibernate und habe meine MySQL Verbindung konfiguriert. Man kann direkt von diesem Dialog aus eine neue DB Verbindung konfigurieren, sofern man das noch nicht getan hat.

Die zwei weiteren dort möglichen Einstellungen habe ich bei mir auf “Use implementation provided by server Runtime” (Die Server Runtime kann in den Properties unter dem Punkt “Targeted Runtimes” konfiguriert werden – verwendet man keinen Server wie den JBoss kann man die JPA Jars auch direkt angeben) und “Discover annotated classes automatically” gesetzt. Anschließend den JPA Facet Dialog und anschließend den Properties Dialog mit “Ok” beenden.

Hat man allerdings den Properties Dialog schon vor den zusätzlichen JPA Einstellungen mit “Ok” beendet muss man noch einmal die Properties für das EJB Projekt aufrufen und kann dann aber den Menüpunkt “JPA” direkt selektieren und somit konfigurieren:

Nachdem die Java Persistence Project Facets dem JEE Projekt hinzugefügt wurden ist im Context Menü, sofern man dieses auf dem EJB Projekt aufruft, der Eintrag “JPA Tools” zu finden. Darin findet sich der Menüpunkt “Generate DDL”.

Erhält man nach dem Auswählen dieses Menüpunktes den Fehler “DDL Generation is not supported by the Generic Platform” hat man vergessen seinen JPA Platform (Hibernate, Toplink, ..) zu konfigurieren. Dazu einfach wieder in die EJB Projekt Properties und den Menüpunkt “JPA” selektieren und konfigurieren. Mehr Informantionen zu dieser Fehlermeldung auch hier.
Ist alles soweit korrekt konfiguriert öffnet sich der DDL Generation Dialog. Darin gibt man zuerst das Zielverzeichnis sowie den Namen der DDL Datei an. Die zweite wichtige Konfiguration ist der Hibernate Dialekt der verwendet werden soll. Dazu kann man entweder eine bereits durch die Hibernate Perspektive erstellte Hibernate Console Konfiguration verwenden und diese mit der Checkbox “Use Console Konfiguration” verwenden oder wie in meinem Fall die bereits konfigurierte Datenbankverbindung. Der Dialekt kann dabei automatisch erkannt werden (ich berichtete darüber) oder direkt angeben:

Ist alles korrekt konfiguriert wird durch den Button “Finish” das Generieren der DDL in der gewünschten Zieldatei gestartet. Das kann einen kleinen Moment dauern und anschließend ist diese Schemadatei auch unter der gewünschten Position (bei mir im EJB-Projekt im Ordner ejbModule) zu finden:

Gerade für die erste Entwicklungszeit und dem Erstellen der Entitäten ist diese einfach DDL Generierung sehr nützlich. Sieht man doch direkt was für Datenbanktypen aus den Java Attributen erstellt werden.

Alternativ kann man mit den Hibernate Tools über die Hibernate Perspektive das Schema auch direkt in der DB erstellen. Vor gut einem Jahr habe ich dazu einen kleinen Artikel erstellt.

Um das QuickFix Verhalten zu verdeutlichen habe ich den Namen der Klasse geändert, so dass dieser nicht mehr mit dem Namen der Datei (QuickFixTests.java) übereinstimmt. In Java ist das nicht erlaubt und somit bietet mir Eclipse mit dem QuickFix Dialog Lösungen an. Hier der Screenshot des Maus Hovers:

Hier der Screenshot des Klicks auf das Warning oder Error Icons links. Ist der Cursor in dieser Zeile kann man auch einfach Strg-1 drücken um diesen Dialog zu erhalten:

Einer der Features überhaupt ist das Generieren von Getter und Setter zu einem Attribut. So spart man sich deutlich Tipparbeit in dem man direkt nach dem Schreiben des Attributes Strg-1 drückt, “Generate getter and setter for ‘attributeName’” selektiert und Enter drückt:

Anschließend erscheint der Dialog für die Getter und Setter Konfiguration, welcher auch über das Context Menü “Source->Generate Getters and Setters..” geöffnet werden kann:

Vor allem die Einstellung an welche Position der Setter und Getter erstellt werden soll ist interessant: sollen die neuen Methoden an die erste oder letzte Stelle in der Klasse oder direkt hinter einer schon bestehenden Methode erstellt werden? Sind die Einstellungen erst einmal gesetzt worden werden sie für die nächste Generieren übernommen. So kann man anschließend die weiteren Getter und Setter ohne großes Konfigurieren schnell generieren.

Ist das Generieren durchgelaufen sind die Getter und Setter natürlich vorhanden:

Interessant an dieser Stelle zu erwähnen ist noch die farbliche Hervorhebung des Attributes. Hat man ein in der Eclipse Menüleiste den Button “Toggle Mark Occurrences” (Alt-Strg-O) eingeschaltet wie im folgenden Screenshot rot hervorgehoben zu sehen:

Dann die Verwendung des gerade mit dem Cursor selektierten Attributes farblich hervorgehoben. Dabei wird farblich zwischen lesenden und schreibenden Aktionen unterschieden. Dieses Verhalten ist im Screenshot davor mit den generierten Getter und Setter schön zu sehen.

Möchte man mit den JBoss Tools 3 arbeiten benötigt man Eclipse Ganymede. Es wird nicht empfohlen von Eclipse 3.3 auf Eclipse 3.4 via Update Manager zu wechseln. Viel praktischer ist es eine frische Eclipse Installation vorzunehmen und somit auch potentielle Fehlerquellen aus dem Weg zu gehen. Am einfachsten ist es wenn man die Eclipse 3.4 IDE for Java EE Developers herunterlädt. Auch hier gibt es mittlerweile das Release 2 Bundle, welches ca 170 MB groß ist.

Nachdem Eclipse heruntergeladen, entpackt und gestartet wurde einfach die JBoss Tools Update URL (http://download.jboss.org/jbosstools/updates/stable) im Eclipse Update Manager hinzufügen. Den Update Manager findet man im Hauptmenü unter Help->Software Updates. Dort den Reiter “Available Software” selektieren und rechts den Button “Add Site…” drücken:

Ist die Update Site hinzugefügt kann man nach dem Aufklappen alle angebotenen JBoss Tools sehen. Für meine Seam Entwicklung mit Hibernate, RichFaces auf dem JBoss AS installiere ich immer die folgende Tools (hervorgehobene Selektion):

Um die Installation fertigzustellen den Button “Install” drücken und den Anweisungen folgen.

Erstellt man über die JBoss Tools ein Seam Web Projekt sieht man schon die erste Erneuerung denn es wird jetzt auch Seam 2.1 direkt unterstützt, wie man auch bei der Konfiguration der Seam Runtime sehen kann:

Wer mit der Nightly Build oder 3.0.0 Alpha Version gearbeitet hat wird die neuen wirklich nützlichen Features wahrscheinlich schon gesehen und ausprobiert haben. Vor allem bei der Entwicklung von Facelets XHTML Seiten in Verbindung mit Seam Komponenten sind sehr schöne Features in die neue Version reingekommen. Ein paar davon, die ich persönlich absolut praktisch finde, sind im folgenden kurz aufgelistet.

Autocompletion:
Es werden alle mit @Name annotierten Seam Komponenten direkt im XHTML Editor gefunden und durch Autocomplete angeboten:

EL Warning:
Hat man eine Fehler in der Expression Language gemacht wie der typische “rechte-Klammer-fehlt” Fehler findet man diesen nun nicht mehr erst nach dem Deployment sondern direkt im Editor durch ein Warning:

Seam Komponenten und Links direkt aus dem Editor heraus öffnen:
Man kann nun direkt aus dem XHMTL Editor heraus durch halten von STRG und der Maus direkt in die Java Klassen der Seam Komponenten oder direkt in andere .xhtml Seiten springen:

Visueller Editor für die pages.xml:
Es gibt nun eine wirklich gute Unterstützung für die pages.xml. Darunter auch eine visuelle Ansicht für die Navigationsregeln, die in der pages.xml definiert werden:

Mehr Bilder zu den neuen Features findet man auch wie gewohnt im Kapitel “News and Noteworthy“.
Alles in allem ist es wirklich schön endlich eine funktionierende und offizielle Version der JBoss Tools für Eclipse Ganymede zu haben. Nun steht der Entwicklung von vielen schönen neuen Seam Projekten nichts mehr im Wege =).

Die offizielle Meldung für die JBoss Tools 3.0 findet man auch noch mal hier zum nachlesen.

Unit Tests sind vielen Entwicklern ein Begriff und in der Java Welt verbindet man diesen Begriff fast automatisch mit dem Testframework JUnit. Dabei steht als genereller Gedanke hinter Unit Tests einzelne kleine Teilbereiche (Units, Methoden, Funktionen) atomar und unabhängig von einer Umgebung und Abhängigkeiten zu testen. Man geht davon aus, dass wenn die einzelnen kleinen Teile eines Systems in Ihrerer Aufgabe funktionieren und diese korrekt tun das große Ganze auch Bestand hat. Dabei gelten nur die Zustände: Erfolg oder Fehler.

In diesem und folgenden Artikeln soll es um den JUnit Konkurrenten TestNG gehen. Das Testframework TestNG ist laut seinem Entwickler Cédric Beust aus der JUnit Frustration entstanden und das NG in TestNG bezieht sich auf Next Generation.

Wer diese Frustration nachlesen möchte kann dies hier und hier tun.

Nicht nur wegen dieser Aussage soll TestNG ein wenig näher begutachtet werden. Wer z.B. mit JBoss Seam arbeitet wird sehr schnell merken, dass Seam von Haus aus eine TestNG Unterstützung mitbringt. Auch andere Frameworks setzen auf TestNG. Aber auch ohne diese Frameworks bietet TestNG eine sehr gute Alternative zu dem schon genannten JUnit.

Das Ziel dieses ersten TestNG Artikels ist einfache TestNG Unit-Tests zu erstellen und aus Eclipse heraus ausführen zu können. In folgenden Artikeln wird es mehr in die Möglichkeiten von TestNG und in die Konfiguration von Tests und Testsuites gehen.

Um TestNG zu verwenden muss die aktuelle Version heruntergeladen werden. Zur Zeit ist die aktuellste Version 5.8 und kann hier direkt heruntergeladen werden.

Es besteht auch eine Eclipse Unterstützung für TestNG, die über eine Update Seite installiert werden kann. Dazu unter Eclipse 3.4 (Ganymede) über “Help->Software Updates…->Available Software Tab->Add Site…” klicken, die TestNG Update Site URL http://beust.com/eclipse angeben und mit “OK” bestätigen. Anschließend das neu hinzugefügte Element aufklappen, das Plugin TestNG selektieren und den Button “Install” drücken.

Bei der Installation den Anweisungen folgen. Es kam bei mir ab und an vor, dass bei der Bestätigung für die zu installierende Software nur ein leeres Fenster auftrat – da einfach mit “OK” weiter klicken.
Nach dem Neustart von Eclipse steht eine TestNG View zur Verfügung und kann geöffnet werden.

Um TestNG aus Eclipse heraus verwenden zu können müss die TestNG Bibliothek noch im Classpath referenziert werden. TestNG liefert zwei jars aus: eine für Java 1.4 (testng-5.8-jdk14.jar) und eine für Java 5 (testng-5.8-jdk15.jar). Beide liegen im heruntergeladenen TestNG.zip im Root Verzeichnis oder alternativ im TestNG Eclipse Plugin Ordner (eclipse\plugins\org.testng.eclipse_5.8.0.2\lib). In meinem Fall kopiere ich mir das testng-5.8-jdk15.jar in meinen im Projekt erstellten lib Ordner und gebe dieses im Projekt Classpath an (Rechte Maustaste auf den Projekt Ordner->Properties->Java Build Path).

Als Beispielprojekt bzw. Beispiel Source Code der getestet werden soll habe ich ein Java Projekt mit zwei Source Ordnern erstellt. Ich persönlich mag es lieber, wenn die Testklassen in einem getrennten Source Ordner liegen. So besteht bei mir der Source Ordner: src und test sowie ein normaler Ordner für die benötigten Java Bibliotheken lib. Unterhalb der zwei Source Ordern erstelle ich zweimal das gleiche Package. Anschließend in dem Ordner src die Klasse de.javathreads.util.Calc und in den Ordner test die Klasse de.javathreads.util.CalcTest. Nach getaner Arbeit sieht die Projektstruktur wie folgt aus:

Nun schauen wir uns den Source Code der zwei Klassen etwas genauer an. Die Klasse de.javathreads.util.Calc beinhaltete die einfachen Methoden add() und divide():

package de.javathreads.util;

public class Calc {

  public int add(int first, int second) {
    return fist + second;
  }

  public double divide(int first, int second) {
    if (second == 0) {
      throw new ArithmeticException();
    }
    return first / second;
  }
}

Um mit TestNG eine Methode zu definieren die den eigentlichen Unit-Test enthält wird diese mit der Annotation org.testng.annotations.Test versehen. Um abzuprüfen ob das Ergebnis dem erwarteten Ergebnis entspricht arbeitet TestNG mit Java Assertions und dem Schlüsselwort assert. Das sieht dann in meiner CalcTest Klasse, welche die Methode Calc.divide() testen soll, wie folgt aus:

package de.javathreads.util;

import org.testng.annotations.Test;

public class CalcTest {

  /**
   * Test für simples dividieren.
   */
  @Test
  public void divideSimple() {
    Calc c = new Calc();
    double sum = c.divide(4, 2);
    assert (sum == 2);
  }

  /**
   * Test für Division durch 0.
   */
  @Test
  public void divideByZero() {
    Calc c = new Calc();
    try {
      c.divide(4, 0);
    } catch (ArithmeticException ex) {
      assert (true);
      return;
    }
    assert (false);
  }
}

Bei einer Prüfung mit dem Schlüsselwort assert muss der Ausdruck immer true ergeben. Mehr zu Java Assertions kann auch in dem javathreads Artikel “Reservierte Schlüsselwörter in Java – Assertions” sowie im Java Blog Buch gefunden werden.

Durch das TestNG Eclipse Plugin ist ein Unit Test sehr einfach durch das Context-Menü direkt aus dem Package Explorer heraus zu starten. Dazu mit der rechten Maustaste direkt auf die Klasse klicken welche die mit @Test annotierten Methoden enthält und anschließend unterhalb des Menüpunkts “Run As” den Punkt “TestNG Test” anklicken:

Es ist auch möglich auf ein Package zu klicken und somit alle darin liegenden Testklassen zu starten.
Nach einem oder mehreren durchlaufenen Unit-Tests wird das Ergebnis in der TestNG View farblich hervorgehoben. Dabei wird farblich gezeigt ob generell alle Test positiv waren (grün) oder mindestens einer fehlgeschlagen ist (rot). Im folgenden ein Screenshot für den Fall das alle Tests positiv waren:

Ist mindestens ein Test fehlgeschlagen wird der Balken schön rot und man die fehlgeschlagene Methode erkennt man durch das rote Kreuz. Selektiert man diesen Test erhält man im rechten Fenster die Exception zu dem Fehler. Bei TestNG sind das immer java.lang.AssertionError, wie man im folgenden Screenshot sehen kann:

Mit einem Doppelklick auf die Methode gelangt man direkt in den Java Editor an die gewünschte Stelle der Testklasse. Es wäre nun auch möglich den Test im Debug Modus zu starten. Dazu anstatt “Run As” einfach den Test mit “Debug As” starten. Dabei natürlich nicht vergessen einen Breakpoint zu setzen ;).

In der Console können noch die Logausgaben und auch das Gesamtergebnis begutachtet werden. Treten Exceptions in der zu testenden Klasse auf sind diese auch in der Konsole sichtbar. Im folgenden die Konsolenausgabe des Positiven Tests:

Als letzte Information zu dieser kleinen Einführung noch der Hinweis, dass TestNG immer mit XML Konfigurationsdateien arbeitet. Der Vorteil wenn das TestNG Eclipse Plugin verwendet wird liegt darin, dass dieses Plugin die XML Datei generiert. Aktualisiert man im Package View das Projekt (Projekt selektieren und F5 drücken) erscheint die Datei temp-testng-customsuite.xml:

Schaut man in diese Konfigurationsdatei rein sieht man wie der einfachste Fall eines TestNG Tests vie XML konfiguriert werden kann. Die Testklasse wird direkt angegeben:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="JavaTestNGProject">
  <test verbose="2" name="de.javathreads.util.CalcTest" annotations="JDK">
    <classes>
      <class name="de.javathreads.util.CalcTest"/>
    </classes>
  </test>
</suite>

Man kann natürlich auch eine solche XML Konfigurationsdatei manuell erstellen und via Eclipse Kontextmenü als TestNG Test ausführen. Dazu legt man sie einfach mit im Test-Source Verzeichnis ab.

In diesem Artikel wurde gezeigt wie man TestNG in Eclipse einbindet und das Eclipse Plugin verwenden kann. Zudem wurde ein sehr einfacher Test geschrieben und ausgeführt. Grundsätzlich ist man nun also in der Lage Tests zu schreiben und diese auch auszuführen, was den ein oder anderen schon deutlich weiter bringen dürfte ;).
Im nächsten Artikel über TestNG wird mehr auf die Möglichkeiten mit TestNG eingegangen. Welche Annotationen gibt es und wie kann man sie einsetzen bzw. wo liegen die Vorteile.