Kapitel 3. Javaprojekte mit Eclipse

Inhaltsverzeichnis

3.1. Grundeinstellungen

Zunächst einmal sollte man dafür sorgen, dass die Sourcecodes grundsätzlich von den erzeugten Class-Files getrennt bleiben. Hierfür ändert man im Dialog „Windows - Preferences“ den Source-Folder-Name auf „src“ und die Output-Location auf „bin“.

Abbildung 3.1. Preference – New Project

Für Web-Applikationen ist es evtl. Geschickter das Output-Verzeichnis gleich so einzustellen, dass alles Class-Files dort landen, wo der Applicationserver sie erwartet („web/WEB-INF/classes“). Das kann man aber auch in der Project-Preferences für jedes Projekt getrennt einstellen.

Abbildung 3.2. Properties – Build output folder

3.1.1. Classpath-Variablen

Ausser der Laufzeit-Bibliothek wird man bei grösseren Projekten sehr schnell andere Bibliotheken mit einbinden müssen. Da diese bei jedem Entwickler auf unterschiedlichen Pfaden installiert sein können, benutzt man sogenannte Classpath-Variablen.

Abbildung 3.3. Preferences – Classpath Variables

Im Projekt werden so nur symbolische Namen gespeichert, die jeder Entwickler auf seine lokale Installation anpassen kann. Braucht man z.B. „servlet.jar“ von Tomcat, dann wird sie im Projekt als „TOMCAT_HOME/common/lib/servlet.jar“ referenziert. Wo Tomcat dann genau installiert ist, wird vom Entwickler selbst festgelegt in dem er den Wert von TOMCAT_HOME entsprechend seiner lokalen Installation einstellt.

3.1.2. Versionierte Namen

Wenn man in einem Team entwickelt und relativ neue Technologien im Einsatz hat, dann ändern sich Versionen der zugehörigen Bibliotheken sehr schnell. Damit nicht das heillose Chaos ausbricht und seltsame Effekte auftreten, die auch noch von einem zum anderen Teammitglied unterschiedlich ausfallen, ist es sehr wichtig, dass alle immer die gleichen Versionen alle Komponenten verwenden.

Deshalb empfehle immer Namen für Bibliotheken zu verwenden, die schon im Namen die Versionsnummer enthalten. z.B. „castor-0.4.1.jar“. Wenn alle Bibliotheken auch so im Projekt referenziert werden, ist sichergestellt, dass alle das Gleiche verwenden.

3.1.3. Erweitern der Dokumentation

Man kann die eingebaute Dokumentation sehr leicht erweitern mit eigenen Texten erweitern. Zum einen lassen sich alle mit JavaDoc erzeugten API-Dokumentationen direkt einbinden. Das gilt zu allererst natürlich für das Java-SDK selbst, aber dann natürlich auch für alle im Projekt benutzten Bibliotheken.

Zum anderen können Plugins ihre Dokumentation nahtlos integrieren, als Beispiel gibt's im Download-Bereich diesen Artikel auf als Plugin, wo durch er eben in der Eclipse Hilfe erscheint.

Abbildung 3.4. Properties für eine Bibliothek

Um die Möglichkeiten voll auszunutzen, sollte man zu jeder verwendeten Bibliothek (JAR-File) die entsprechende API-Dokumentation, sowie den Sourcecode (soweit verfügbar) zuordnen. Wenn man ein komplettes JDK installiert inklusive Source erkennt Eclipse das automatisch. Für alle individuellen Bibliotheken ordnet man über die Properties eines jeden JARs (erreichbar über das Kontextmenü) die Dokumentation und das Source-Archiv zu.

Entsprechend wird auch die API-Dokumentation des eigenen Projekts mit eingebunden:

Abbildung 3.5. Properties – eigene Dokumentation einbinden

So vorbereitet liefert den Druck auf Shift-F2 jederzeit die Dokumentation zum Objekt unter dem Cursor, genauso wie F3 das betreffende Sourcefile öffnet.

3.1.4. Beispielprojekt für Tomcat

Dies Beispiel soll zeigen, wie man zunächst noch ohne spezielle Unterstützung von Plugins ein Projekt mit Tomcat aufbaut. Der Package-Explorer zeigt folgende Struktur:

Abbildung 3.6. Tomcat Projektstruktur

Neben dem src Verzeichnis gibt es bei WebApplications immer das Verzeichnis „web“ und darin das „WEB-INF“, das alle Metainformationen und die zu erzeugenden Class-Files enthält. Die Output-Build-Location (siehe oben) wurde so umgestellt, dass die erzeugten Class-Files direkt im „classes“ landen.

Daneben sind alle „normalen“ Web-Resourcen wie HTML-Dateien, Grafiken usw. in „web“ untergebracht. Auch die JSP-Seiten werden dort angelegt.

Grundsätzlich reicht das schon aus, um eine erste Anwendung mit Tomcat zu erstellen. Das Deployment ist allerdings noch nicht sehr komfortabel: man muss alle Dateien des Workspaces unter „web“ in ein Verzeichnis unter das WebApps-Verzeichnis von Tomcat kopieren und anschließend Tomcat neu starten. Das geht entweder ganz manuell mit einem Script oder per Export mit Eclipse im File-Menü.

Während der Entwicklungsphase kann man sich das Deployment aber auch schenken und stattdessen einen Tomcat-Context erzeugen, der direkt auf die WebApplication im Workspace von Eclipse verweist. Hierzu wird ein Eintrag in der server.xml in TOMCAT_HOME/conf von Tomcat erstellt:

<Context reloadable = "true" displayName="Develop"
docBase="C:\Programme\eclipse\workspace\Test-Servlet\web" cookies="true"
path="/test"/> 

Diesen Eintrag fügt man hinter die anderen Kontexte ein und startet Tomcat neu.

Was dann aber immer noch nicht geht, ist das Debuggen der Application. Diese speziellen Aspekte werden in den Kapiteln 7 und 8 erläutert.