Leseprobe

Kapitel 2 

Entwicklungsumgebungen 

2.1 Integrierte Entwicklungsumgebung (IDE) 21 

2.2 Versions-/Releasemanagement-System 46 

2.3 Automatische Build-Umgebung 53 

2.4 Fazit 62

20 

Zu Beginn eines jeden Software-Projekts stellt sich die Frage nach der eingesetzten 

Entwicklungsumgebung. Die hier gemachten Entscheidungen haben maßgeblichen 

Einfluss auf die weitere Entwicklung. 

Zu der Entwicklungsumgebung gehören zahlreiche Komponenten für die unterschiedlichen 

Projektphasen. Eines der Hauptziele beim Definieren der Entwicklungsumgebung 

ist es daher, eine möglichst reibungslose Zusammenarbeit der 

Werkzeuge zu gewährleisten. Je weniger Brüche es im Entwicklungsprozess gibt, 

umso größer ist die Chance, dass auch alle Werkzeuge während der Entwicklung 

von den Projektmitgliedern genutzt werden. 

So ist es beispielsweise sehr sinnvoll und auch wünschenswert, den Build- und 

Release-Vorgang automatisiert ablaufen zu lassen. Ist der Aufwand, der dafür zu 

betreiben ist, zu hoch, um während der Entwicklung genutzt zu werden, ist die 

Gefahr groß, dass sich jeder Entwickler sein eigenes Vorgehen dafür baut. 

Grundsätzlich beschränkt sich die Definition der Entwicklungsumgebung nicht 

nur auf die Auswahl von Werkzeugen, die der Erstellung von Source Code dienen. 

Ebenso wichtig sind etwa Werkzeuge für die Verwaltung und Versionierung 

der Quellen und den automatisierten Build- und Deployment-Vorgang. 

Daneben beinhaltet die Entwicklungsumgebung auch einige definierte Verfahren, 

wie und wann die entsprechenden Werkzeuge eingesetzt werden. So ist es beispielsweise 

sehr sinnvoll, das Versions- und Releasemanagement vor Beginn der 

Entwicklung festzulegen. 

Im folgenden Kapitel werden eine Reihe von Open Source-Werkzeugen für die 

Java-Software-Entwicklung vorgestellt. Durch die richtige Auswahl steht eine 

hochgradig integrierte Umgebung zur Verfügung, die sich sehr gut mit kommerziellen 

Produkten messen kann. Zum Teil sind bei den Open Source-Vertretern 

sogar bessere Erweiterungsmöglichkeiten gegeben. 

AUSBLICK AUF DAS KAPITEL 

Das folgende Kapitel stellt anhand der zurzeit am gebräuchlichsten 

Open-Source-Werkzeuge eine komplette Entwicklungsumgebung zusammen. 

Hierbei werden neben den Funktionalitäten der einzelnen Werkzeuge 

auch deren Integrationsmöglichkeiten betrachtet. Je besser die 

Werkzeuge miteinander zusammenarbeiten, umso durchgängiger werden 

die darauf aufsetzenden Entwicklungsprozesse. 

Besonders deutlich wird die Leistungsfähigkeit mancher Open Source-Entwicklung, 

wenn man sieht, wie viele kommerzielle Umgebungen im Kern auf der Open Source- 

Variante basieren. 

Für die hier betrachtete Beispielanwendung wird eine Entwicklungsumgebung 

mit folgenden Komponenten aufgesetzt: 

1. Integrierte Entwicklungsumgebung (IDE) 

2. Versions-/Releasemanagement-System

Kapitel 2 • Entwicklungsumgebungen 21 

3. Build-Werkzeug für automatisierten Build/Deploy 

4. Testumgebung (Server) 

Bis auf die Testumgebung werden die dafür verwendeten Werkzeuge im folgenden 

Kapitel näher betrachtet und mit anderen verfügbaren Werkzeugen verglichen. 

2.1 Integrierte Entwicklungsumgebung (IDE) 

Die meiste Zeit wird der Entwickler wohl bei der reinen Entwicklung der Java- 

Quellen verbringen. Obwohl in der Regel auch ein einfacher Texteditor für die 

Erstellung der Quellen ausreicht, bietet eine integrierte Entwicklungsumgebung 

(IDE) zahlreiche Funktionen, die den Komfort bei der Entwicklung erhöhen. 

Standardmäßig bieten wohl alle die folgenden Funktionalitäten: 

• Syntax Highlighting (farbliche Hervorhebung der Schlüsselworte) 

• Projektverwaltung (Gruppierung der Quellen in Projekte) 

• Compile/Starten der Anwendung aus der Oberfläche 

• Starten des Java-Debuggers 

2.1.1 Emacs/XEmacs 

Die genannten Funktionalitäten sind allerdings schon mit den meisten kommerziellen 

und auch freien Editoren umzusetzen. Neben verschiedenen in Java geschriebenen 

Texteditoren kommt man bei der Betrachtung nicht an der Entwicklungsumgebung 

vorbei. Emacs/Xemacs (http://www.xemacs.org) bietet für nahezu jede Programmiersprache 

die entsprechende Umgebung. Syntax Highlighting, Projektverwaltung, 

Compilen und Starten des Debuggers sind dabei die absolute Minimalausstattung. 

Mit der aktuellen Version wird zusätzlich für die Entwicklung mit Java die 

JDEE(Java Development Environment for Emacst)-Erweiterung (http://jdee.sunsite.dk/rootpage.html) 

mitgeliefert. Zusätzlich zu den bereits genannten stehen dem 

Entwickler folgende Funktionalitäten zur Verfügung: 

• Code Completion 

• Automatisches Einfügen von Import Statements 

• Automatisches Einfügen von Javadoc-Kommentaren 

• Online-Hilfe über Javadoc Integration 

• Springen zur Typdeklaration 

• Klassenbrowser 

• Jakarta ANT Integration 

• usw.

22 

Integrierte Entwicklungsumgebung (IDE) 

Entwickler, die von der Arbeitsweise mit dem XEmacs überzeugt und darin geübt 

sind, werden die erweiterten Möglichkeiten der JDE auf jeden Fall zu schätzen 

wissen. Wie im XEmacs üblich, sind alle Aktionen direkt über einfache Tastenkombinationen 

erreichbar. Der geübte XEmacs-Entwickler wird unter Windows 

die Maus daher wahrscheinlich nur benutzen, um den Rechner herunterzufahren 

oder seine erstellte Webanwendung im Browser zu testen. Nebenbei bemerkt 

könnte er auch das über den im XEmacs integrierten Browser erledigen. 

Bei der Verwendung des XEmacs als Entwicklungsumgebung stehen direkt auch 

die sonstigen Funktionalitäten wie CVS-Integration, XML Mode, C++ Mode, 

Make File Mode oder etwa HTML und JSP zur Verfügung. Damit ist und bleibt 

XEmacs die wohl meist integrierte Entwicklungsumgebung, die es für die Software-Entwicklung 

gibt. 

HINWEIS 

Einziger Kritikpunkt, der häufig gegen die Verwendung des XEmacs vorgebracht 

wird, sind die zu erlernenden Tastenkombinationen. Dieser 

Nachteil ist für die Befürworter des XEmacs allerdings gerade der Hauptvorteil 

der Umgebung. 

2.1.2 jEdit Java Programmers Editor 

Der in Java geschriebene Editor ist nach seiner Standardinstallation nichts weiter 

als ein Texteditor. Die Architektur von jEdit ermöglicht allerdings die Erweiterung 

der Funktionalität durch Hinzuladen von so genannten Plug-Ins. Durch die 

Hinzunahme der entsprechenden Plug-Ins entsteht eine sehr komfortable Entwicklungsumgebung. 

Durch die modulare Architektur ist es jedem Entwickler 

auch möglich, spezielle Plug-Ins für sich zu entwickeln und in seine Umgebung 

aufzunehmen. 

Nach der Installation werden bereits ca. 70 Programmiersprachen erkannt und im 

Editor die Schlüsselworte bereits farblich markiert. Bei der ersten Verwendung 

des Editors erhalten Sie schon einen Eindruck von seiner guten Performance. 

Obwohl es sich um eine reine Java SWING-Anwendung handelt, reagiert der Editor 

auf meinem Laptop ohne merkbare Verzögerung und ermöglicht eine zügige 

Arbeitsweise beim Edieren. 

Im Folgenden möchte ich anhand einer Beispielinstallation von jEdit die notwendigen 

Plug-Ins und deren Verwendung kurz vorstellen. Auf den Downloadseiten 

oder auf der beiliegenden CD findet Sie die letzte Version des Editors. Nach dem 

Entpacken des ZIP-Archivs liegt im Installationsverzeichnis die Anwendung 

jEdit.exe. Beim ersten Start der Anwendung wird ein kurzer Installationsvorgang 

ausgeführt. Dabei muss nur noch das Verzeichnis der lokalen JSDK-Umgebung 

angegeben werden. Es muss sich dabei um eine vollständige Installation der Java 

SDK handeln, da für das Compilen der Java-Klassen der JSDK Compiler verwendet 

wird.


Abbildung 2.1: 

Auswahl des Java SDK Bin-Verzeichnisses 

Nach der Installation startet der Editor. Als Nächstes sind nun die für die Java- 

Entwicklung notwendigen bzw. sinnvollen Plug-Ins zu installieren. Dazu ist über 

das Menü PLUGINS/PLUGIN MANAGER der Plug-In-Manager zu starten. 

Der Plug-In-Manager lädt die Liste der aktuell verfügbaren Plug-Ins von der jEdit- 

Webseite. Zu jedem Plug-In gibt es ein kurze Information über den Autor und den 

Inhalt. Neben den hier für die Java-Entwicklung ausgewählten Plug-Ins lohnt sich 

auch ein Blick auf die anderen, die interessante Erweiterungen für die Oberfläche 

selber liefern. 


Plug-In-Manager-Dialog inklusive Plug-In-Informationen

24 


Sofern man daran interessiert ist, sich eigene Erweiterungen in Form von jEdit- 

Plug-Ins zu schreiben, sollte für die hier ausgewählten Plug-Ins auch der Source 

Code mitgeladen werden. Dieser bietet neben der sehr guten API-Dokumentation 

die beste Möglichkeit, sich schnell mit der Verwendung der API vertraut zu 

machen. 

Für die Entwicklung mit jEdit sind vor allem die folgenden Plug-Ins notwendig, 

bzw. zu empfehlen. 

AntFarm BufferTabs Class Wizzard 

Common Controls Console ContextHelpDebugger 

Debugger ErrorList Java Insight 

Refactor JavaStyle Java Browser 

JCompiler JDiffPlugin Project Viewer 

SpeedJava Templates TomcatSwitch 

WheelMouse WhiteSpace XML 

XSLT 

Tabelle 2.1: 

Empfohlene Plug-Ins für jEdit 

Nach der Auswahl und anschließenden Installation der Plug-Ins muss jEdit neu 

gestartet werden, damit alle neuen Funktionen zur Verfügung stehen. Anhand des 

folgenden Beispielprogramms werde ich die wichtigsten und interessantesten 

Funktionen der Entwicklungsumgebung darstellen. Alle Plug-Ins finden sich unter 

dem Menü PLUGINS 1. Sobald der Platz in diesem Menü nicht mehr ausreicht, werden 

neue Menüs eingeführt, die jeweils durchnummeriert werden. 

Manche Plug-Ins bieten die Möglichkeit, konstant aktiviert zu werden. In diesem 

Fall findet sich im Plug-Ins-Menü eine Checkbox neben dem Menüpunkt. Zu 

Beginn der Arbeit bietet sich die Aktivierung der Plug-Ins BUFFERTABS und PRO- 

JECTVIEW an. Über das erste können alle geöffneten Buffer direkt über einen Reiter 

angesprochen werden. Der ProjectView dient der Verwaltung von Projekten, also 

einer Zusammenfassung von Dateien einer Anwendung. Die Projektverwaltung 

steht nach der Aktivierung im Plug-Ins-Menü als eigenes Fenster zur Verfügung, 

sodass man leicht zwischen dem Editor und der Projektansicht wechseln kann. 

In der Projektverwaltung werden definierte Projekte in einem Baum dargestellt. 

Zur Bearbeitung der Dateien stehen verschiedene Ansichten zur Verfügung. Unter 

dem Reiter FOLDERS werden die im Projekt enthaltenen Dateien entsprechend 

ihrer Lage im Dateisystem abgebildet. Der Reiter FILES wiederum zeigt alle 

Dateien des Projekts als Liste ohne Verzeichnisstruktur an. Der letzte Reiter WOR- 

KING FILES stellt nur die aktuell zur Bearbeitung geöffneten Dateien als Liste dar. 

Es können Projekte angelegt und gelöscht werden, Dateien in ein Projekt eingebunden 

werden und auch wieder aus einem Projekt entfernt werden. Hierbei ist 

wichtig zu verstehen, dass es sich nur um eine logische Strukturierung von


Dateien handelt. Beim Entfernen eines Projekts oder von Dateien aus einem Projekt 

werden diese nicht wirklich gelöscht. Es wird lediglich die Beziehung zum 

jeweiligen Projekt aufgehoben. Dadurch können für einzelne Arbeitspakete nur 

die wirklich benötigten Dateien aus einem Gesamtprojekt ausgewählt werden. 

Dadurch lässt sich die Arbeit in großen Projekten mit zahlreichen Klassen deutlich 

übersichtlicher gestalten. 

Zum Anlegen eines einfachen Projekts kann der CREATE NEW PROJECT-Button in 

der Symbolleiste der Projektverwaltung verwendet werden. Nach Angabe des 

Projektnamens und des Startverzeichnisses können abschließend noch bereits 

existierende Dateien eingebunden werden. 


Projektverwaltung in jEdit 

Beim Einlesen der Dateien werden alle Unterverzeichnisse des Startverzeichnisses 

des Projekts nach Dateien durchsucht. Diese werden dann direkt in das Projekt 

mit aufgenommen. Für das folgende Beispiel dient ein Verzeichnis mit nur 

einer Java-Datei. 

Wie gewohnt startet ein Doppelklick auf eine Datei in der Projektverwaltung den 

Editor zum Bearbeiten der Datei. Bevor mit dem Bearbeiten der Dateien begonnen 

wird, können Sie sich erst einmal die Oberfläche nach Ihrem Geschmack 

anpassen. Dabei geht jEdit einen etwas ungewöhnlichen, aber auch ungewöhnlich 

flexiblen Weg zur Konfiguration. Fenster der Plug-Ins wie etwa die Projektverwaltung 

oder die ErrorList können entweder als eigenständige Fenster gestartet 

oder an das Hauptfenster angedockt werden. Hier kann für jedes Plug-In explizit 

seine Position am Bildschirm ausgewählt werden. Der entsprechende Dialog findet 

sich unter dem Menü UTILITIES/GLOBAL OPTIONS/DOCKING. Nachdem man 

sich für die Position der Fenster entschieden hat, können noch die Tastenkombinationen 

an die eigenen Bedürfnisse angepasst werden. Auf Grund der sonst 

etwas unhandlichen Verwendung der Plug-Ins ist das zumindest für die am häufigsten 

verwendeten Funktionen zu empfehlen. Zu finden sind die Einstellungen 

im gleichen Dialog unter SHORTCUTS. Über eine Auswahlliste können nun alle 

Funktionen, die auch über Menüs zur Verfügung stehen, mit einer Tastenkombination 

versehen werden. 

Nachdem nun alle Einstellungen vorgenommen worden sind, steht eine ausgereifte 

Entwicklungsumgebung zum Erstellen von Java-Dateien zur Verfügung. 

Die zur Verfügung stehenden Plug-Ins bestechen durch überraschende, aber sinn-

26 


volle Funktionalitäten. Aber auch die Anwendung selber hat schon eine Reihe 

ungewöhnlicher Funktionalitäten. So ist es beispielsweise möglich, den Quelltext 

nach bestimmten Kriterien auf- und zuzuklappen. So kann ausgehend von der 

Einrückung der Inhalt einer Methode zusammengeklappt werden, sodass nur 

noch der Methodenkopf und die geschweiften Klammern sichtbar sind. 


Zusammenklappen von Source Code 

Die Dokumentation der Plug-Ins ist in der Regel recht ausführlich und wie die 

restliche Dokumentation auch sehr professionell erstellt. Nach der Installation 

wird die Dokumentation eines Plug-Ins auch in die bestehende Online-Hilfe von 

JEdit integriert. 

Alles in allem bekommt der Entwickler mit JEdit und verschiedenen Plug-Ins 

eine sehr flexible und leistungsstarke Umgebung für die Erstellung und Verwaltung 

von Java-Quelldateien. Bisher leider nicht als Plug-In verfügbar ist eine Integration 

in ein Versionsmanagement-Werkzeug. Hier gehört eigentlich eine 

Integration in CVS mittlerweile zum Standard. Besonders fällt wiederum die gute 

Performance von jEdit im Vergleich zu anderen Java Swing-Anwendungen auf. 

Das Vorurteil, Java-Anwendungen taugen nicht für anspruchsvolle Anwendungen, 

ist auch deutlich widerlegt.


jEdit bietet in der aktuell verfügbaren Version bereits eine Reihe nützlicher 

Funktionalitäten, die über das normale Syntax Highlighting hinausgehen. Auf 

Grund der fehlenden Integration in bestehende Versionierungs-Werkzeuge ist 

jEdit für den Einsatz in Projekten mit vielen Entwicklern eher nicht gut geeignet. 

Durch die große Zahl der unterstützten Programmiersprachen und die zum Teil 

sehr innovativen Plug-Ins stellt jEdit auf jeden Fall einen sehr guten Ersatz für 

die bisher verwendeten Editoren dar. Hier kommt auch die durch Java gegebene 

Plattformunabhängigkeit zum Tragen. jEdit ist auf allen Plattformen lauffähig, 

auf denen eine Java-Laufzeitumgebung zur Verfügung steht. 

2.1.3 Netbeans/Sun Forte for Java 

Nachdem es sich bei den beiden bisher betrachteten Werkzeugen um sehr leistungsfähige 

Editoren handelt, erhebt Netbeans den Anspruch, eine vollständige 

Entwicklungsumgebung zu sein, die den Entwickler in allen Phasen der Software- 

Entwicklung unterstützt. 

Konkret handelt es sich hier um zwei Anwendungen, die im Kern auf der Open 

Source-Plattform Netbeans (http://www.netbeans.org) basieren. Netbeans versteht 

sich dabei nicht in erster Linie als eine Entwicklungsumgebung, sondern 

vielmehr als eine flexible Anwendungsplattform, auf deren Basis verschiedenste 

Anwendungen entstehen können. Netbeans stellt dafür sozusagen die notwendige 

Infrastruktur zur Verfügung, auf der dann so genannte Module nachgeladen werden 

können. Ähnlich dem in JEdit verwendeten Plug-In-Verfahren wird die Funktionalität 

der Umgebung über zusätzliche Plug-Ins erweitert. 

Gestartet wurde das Open Source-Projekt von zwei Studenten in Tschechien, die 

eigens dafür die Firma Netbeans gegründet haben. Nach den ersten Versionen 

wurde die Firma von Sun aufgekauft und das Produkt als Closed Source-Projekt 

unter dem Namen Forte for Java Community Edition weitergeführt und im Oktober 

1999 auf den Markt gebracht. Obwohl auch in den Anfängen von Forte for 

Java eine freie, wenn auch abgespeckte Version zur Verfügung stand, hat Sun versucht, 

eine erweiterte Version als kommerzielles Produkt zu vermarkten. Auf 

Grund von strategischen Entscheidungen wurde der Kern der Anwendung jedoch 

im Juni 2000 als Open Source-Projekt unter der heutigen Adresse im Internet 

veröffentlicht. Gleichzeitig vertreibt Sun immer noch eine kommerzielle Version 

mit erweiterten, auf den hauseigenen J2EE-Applikationsserver zugeschnittenen 

Funktionen. 

Auf den Internetseiten der Netbeans.org findet sich neben der eigentlichen Plattform 

auch eine integrierte Entwicklungsumgebung auf Basis der Plattform. 

Grundsätzlich entstehen neue Anwendungen auf der Netbeans-Basis durch Hinzufügen 

von so genannten Modulen. Diese können auch wieder zur Laufzeit über 

die Netbeans-Oberfläche hinzugeladen und administriert werden. Eine Internetverbindung 

vorausgesetzt, können neuere Versionen direkt in die Oberfläche integriert 

werden.

28 


Schon während des Downloads merkt man, dass es sich bei Netbeans um eine 

andere Kategorie von Anwendungen handelt, als etwa bei jEdit. Beläuft sich die 

Downloadgröße bei jEdit auf ca 1,8 MB, so werden bei Netbeans in der Version 

3.3.2 schon allein ohne besondere Module knappe 15 MB geliefert. Nach der Installation 

und ein paar zusätzlichen Modulen sind leicht 50–60 MB auf der Platte belegt. 

Nach der Installation steht allerdings auch eine Entwicklungsumgebung zur Verfügung, 

die sich in Hinblick auf die vorhandenen Möglichkeiten vor kommerziellen 

Produkten keinesfalls verstecken muss. Für eine genauere Betrachtung, ohne 

Anspruch auf Vollständigkeit, soll im Folgenden ein kurzes Projekt dienen. Dabei 

kann auf die Besonderheiten der Oberfläche eingegangen werden und es können 

einige der interessanten Funktionen dargestellt werden. Um die bereits standardmäßig 

vorhandene Integration der Umgebung in bestehende Laufzeitumgebungen 

wie etwa J2EE Container und Java Servlet Container zu zeigen, werde ich im Folgenden 

eine Anwendung auf Basis der Java Servlet API realisieren. Besonders 

von Vorteil ist die Umgebung, wenn es darum geht, Laufzeitfehler eines Servlets 

bzw. einer Java Server Page zu finden. Netbeans liefert hier zum Beispiel hervorragende 

Möglichkeiten des Debuggings von serverseitigen Anwendungen. 

Netbeans-Oberflächenkonzepte 

Netbeans bietet die Möglichkeit, in zwei verschiedenen Darstellungsformen zu 

laufen. Dabei unterscheiden sich die Betriebsarten in der Darstellung der Fenster. 

Im SDI-Modus liegen alle Teile in einem separaten Anwendungsfenster. Im MDIoder 

FULL SCREEN-Modus gibt es nur ein Anwendungsfenster, in das die übrigen 

Fenster eingebettet werden. Während der Installation von Netbeans können Sie 

das konfigurieren. Ein Umschalten der Betriebsarten ist aber auch nach der Installation 

über den Menüpunkt TOOLS/SETUPWIZARD möglich. 


Auswahl der Betriebsart von Netbeans


In den nachfolgenden Beispielen wird jeweils der MDI-Modus verwendet. Dieser 

bietet die von anderen Entwicklungsumgebungen und sonstigen Anwendungen 

gewohnte Dreiteilung der Oberfläche. Am linken Rand befindet sich eine Navigation, 

im mittleren Bereich das aktuelle Dokument und am unteren Rand optionale 

Status- bzw. Detailinformationen. 

Wichtig für die korrekte Verwendung der Oberfläche ist das Verständnis der verwendeten 

Konzepte und Begriffe. Im Folgenden werden die wichtigsten Begriffe 

und deren Bedeutung kurz erläutert. 

Filesystem 

Im linken Teil der Oberfläche befindet sich unter dem Reiter FILESYSTEMS eine 

hierarchische Anzeige der verfügbaren Verzeichnisse und Dateien. Um auf 

Dateien zuzugreifen, muss das entsprechende Filesystem in Netbeans geladen 

(mount) werden. Als erste Besonderheit fällt auf, dass der im Rest der Entwicklungsumgebung 

verwendete Klassenpfad auf den verfügbaren Filesystemen 

basiert. Das bedeutet, alles was in einem Filesystem erreichbar ist, liegt auch im 

Klassenpfad. Als Filesystem können neben echten Verzeichnissen auch direkt 

ZIP- bzw. JAR-Dateien sowie Arbeitsverzeichnisse von verschiedenen Versionsmanagement-Werkzeugen 

eingebunden werden. 

Project 

Dateien, die sich nur auf ein bestimmtes Projekt beziehen, können in Netbeans in 

so genannten Projects gruppiert werden. Dies ist von Vorteil, wenn die Navigation 

in den Filesystemen auf Grund deren Anzahl zu komplex geworden ist. Innerhalb 

von Projekten ist es auch möglich, Aktionen auf alle Dateien des Projekts auszuführen, 

etwa das Compilen aller Java-Quelldateien. 

Workspace 

Als Workspace wird in Netbeans die Sammlung verschiedener Anwendungsfenster 

bezeichnet, die für eine Aufgabe benötigt werden. Während des Editierens von 

Source Code wird neben dem Projektbrowser noch der Texteditor benötigt. Beim 

Debuggen werden dagegen neben den Quelltexten auch noch Fenster für die Darstellung 

von Variableninhalten benötigt. Über Reiter am oberen Rand kann direkt 

zwischen den Workspaces gewechselt werden. 

Wie schon erwähnt, handelt es sich bei Netbeans nicht in erster Linie um eine 

reine Entwicklungsumgebung. Es wurde vielmehr versucht, eine offene Plattform 

zu entwerfen, auf deren Basis dann beliebige Anwendungen aufsetzen können. 

Im Grunde stellt die Netbeans-IDE eben eine solche Anwendung dar. 

Für die Erweiterung der Funktionalitäten der Netbeans-Plattform steht dem Entwickler 

die Open API als Schnittstelle zur Erstellung von Netbeans-Modulen 

bereit. Module sind einzelne Erweiterungen, die zur Laufzeit in die Oberfläche 

integriert werden können. In die Java-Entwicklungsumgebung sind bereits die für 

die Java-Entwicklung wichtigsten Module eingefügt. Über den SETUP WIZARD 

können Module aktiviert und deaktiviert werden.

30 



Hauptfenster von Netbeans 


Konfiguration der Netbeans-Module


Projekt anlegen 

Als ersten Schritt bei der Entwicklung sollte ein neues Projekt in Netbeans angelegt 

werden. Im Projekt werden alle relevanten Dateien einer Anwendung zusammengefasst. 

Projekte können in Netbeans über den Projektmanager verwaltet werden, der über 

den Menüpunkt PROJECT/PROJECT MANAGER aufgerufen wird. Die Informationen 

der Projekte werden hierfür an zentraler Stelle im Projektverzeichnis abgelegt 

und verwaltet. 

Nach dem Anlegen eines neuen Projekts im Projektmanager können zum einen 

bereits existierende Filesysteme in das Projekt aufgenommen, und auch direkt 

neue Objekte angelegt werden. 

Zum Anlegen von neuen Elementen bietet Netbeans die Möglichkeit, über eine 

Reihe so genannter Templates das Erzeugen zu vereinfachen. Templates dienen 

dabei als Vorlage für neue Dateien und Verzeichnisse. Neben den zahlreich vorhandenen 

Standard-Templates lassen sich auch eigene neue erzeugen. Hier können 

bestehende Templates als Vorlage verwendet werden oder aber auch ein 

kompletter Workspace als Template gespeichert werden. Verglichen mit ähnlichen 

Template-Mechanismen in anderen Entwicklungsumgebungen bieten die Templates 

in Netbeans den Vorteil, dass sich dadurch direkt eine Reihe von Dateien 

gleichzeitig anlegen lassen. Einfachstes Beispiel für die Verwendung ist die Definition 

einer Standard-Verzeichnisstruktur für alle Web-Projekte. Zu Beginn eines 

jeden neuen Web-Projektes können dann neben den üblichen Verzeichnissen und 

Konfigurationsdateien auch gleich die in der Abteilung üblichen sonstigen Verzeichnisse 

mitangelegt werden wie zum Beispiel ein Verzeichnis für die Ablage 

der Dokumentation oder benötigter SQL-Scripts. 

Die vorhandenen Templates können in der Entwicklungsumgebung über den Menüpunkt 

TOOLS/OPTIONS unter dem Abschnitt SOURCE CREATION AND MANAGEMENT 

verändert werden. Zum Öffnen und Editieren eines Templates ist dieses in der Baumansicht 

mit der rechten Maustaste auszuwählen und der Menüpunkt OPEN zu wählen. 


Templates-Dialog

32 


Nach dem Bearbeiten kann das neue Template einfach gespeichert werden und 

steht danach in der neuen Version zur Verfügung. 

Als erstes Beispiel bietet es sich an, das Template für gewöhnliche Java-Klassen 

(Class) zu modifizieren. Wie in Open Source-Projekten üblich, wird vor der 

eigentlichen Klassendeklaration die Lizenzvereinbarung eingefügt. 

Das in Abbildung 12.8 ausgewählte Template Class enthält nach der Installation 

folgende einfache Klassendeklaration: 

Listing 2.1: 

Standard Class-Template 

/* 

* __NAME__.java 

* 

* Created on __DATE__, __TIME__ 

*/ 

package Templates.Classes; 

/** 

* 

* @author __USER__ 

*/ 

public class Class { 

/** Creates a new instance of __NAME__ */ 

public Class() { 

} 

} 

Im Quelltext des Templates befinden sich auch schon einige so genannte Makros, 

die zur Laufzeit durch die entsprechenden Werte ersetzt werden. Eine Liste der in 

Templates möglichen Makros befindet sich in der Online-Hilfe zur Entwicklungsumgebung. 

Makros beginnen und enden immer mit einem doppelten Unterstrich. 

Dazwischen steht der Name des Makros, der auch wieder Unterstriche enthalten 

darf. Das Makro __NAME__ beispielsweise wird durch den Namen der neu 

erzeugten Klasse ersetzt. 

In den Quelltext kann jetzt einfach der gewünschte zusätzliche Text eingefügt 

werden. Anstelle des Lizenztextes füge ich an dieser Stelle eine abgewandelte 

Implementierung der toString()-Methode in das Template ein. 

Listing 2.2: 

Modifiziertes Class-Template 

/* 

* __NAME__.java 

* 

* Created on __DATE__, __TIME__ 

*/ 

package Templates.Classes; 

/** 

*


* @author __USER__ 

*/ 

public class Class { 

/** Creates a new instance of __NAME__ */ 

public Class() { 

} 

} 

public String toString() { 

String parentToString = super.toString(); 

return "Generated using Netbeans Template" 

+ parentToString(); 

} 

Auf diesem Weg sollten die am häufigsten benötigten Templates eines Projektes 

identifiziert und dementsprechend angepasst werden. Je mehr während der Entwicklung 

auf standardisierte Templates zurückgegriffen wird, umso besser werden 

sich die Projektbeteiligten im Quelltext zurechtfinden. Die Lesbarkeit wird 

stark verbessert und damit auch die Wartbarkeit der Anwendungen. 

Nach den ersten Vorbereitungen kann im neuen Projekt direkt mit der Entwicklung 

begonnen werden. Als erstes Beispiel soll eine einfache Klasse auf Basis des 

eben modifizierten Templates erstellt werden. 

Nachdem das Projekt neu angelegt und geöffnet worden ist, steht es im linken Teil 

der Netbeans-Oberfläche zur Verfügung. Dateien des Projekts werden in einem 

Baum angezeigt, der zu Beginn noch komplett leer ist. Zum Hinzufügen neuer 

Elemente zu einem Projekt ist ein Knoten in der Baumansicht zu wählen und entweder 

über das Kontextmenü (rechte Maustaste) oder FILE/NEW der NEW WIZARD 

zu starten. Der Dialog bietet alle vorhandenen Templates zur Auswahl an. Wählt 

man hier das Template Class aus, werden in den nächsten Schritten des Dialogs 

noch der Name sowie das Package der Klasse abgefragt. Zusätzlich können in diesem 

Dialog auch schon Vererbungen angegeben und Methoden und Attribute für 

die Klasse definiert werden. 

Für das einfache Beispiel hier werden bis auf den Namen und die Position im 

Filesystem keine Angaben für die neue Klasse benötigt. Daher wird der NEW 

WIZARD nach dem zweiten Dialog mit dem FINISH-Button direkt abgeschlossen. 

Als Ergebnis erhalten Sie eine neue Klasse im Projekt, deren Quelltext auf dem 

eben modifizierten Class-Template basiert. Um ein lauffähiges Java-Programm zu 

bekommen, müssen Sie nur noch eine einfache Main-Methode hinzufügen. 

Nun kann die neue Klasse direkt über den Menüpunkt BUILD/COMPILE übersetzt 

werden. Nachdem die Klasse in Netbeans kompiliert wurde, bekommt sie in der 

Baumansicht des Projekts noch einen zusätzlichen grünen Pfeil. Damit werden in 

Netbeans alle Elemente eines Projektes gekennzeichnet, die direkt aus der Entwicklungsumgebung 

gestartet werden können.

34 



New-Wizard zum Anlegen neuer Elemente im Projekt 


Ausführbares Element in Netbeans 

Alle so gekennzeichneten Elemente können über den Menüpunkt EXECUTE des 

Kontextmenüs des Knotens direkt ausgeführt werden. Abgesehen von der Tatsache, 

dass zum Ausführen automatisch auf einen anderen Workspace gewechselt 

wird, ist die Ausgabe der Anwendung nicht sehr spannend. Wichtig ist an dieser 

Stelle nur, dass nicht nur reine Java-Klassen in Netbeans direkt ausgeführt werden 

können, sondern zum Beispiel auch Java Servlets oder Java Server Pages.


Anlegen einer Webanwendung 

Im Gegensatz zu einfachen Java-Anwendungen benötigt eine Webanwendung 

neben den eigentlichen Java-Klassen für die Logik noch eine Reihe von speziellen 

Verzeichnissen und Konfigurationsdateien. In der J2EE-Spezifikation ist für 

Java Servlets und Java Server Pages folgende Verzeichnisstruktur definiert: 


Verzeichnisstruktur einer Webanwendung 

Das Hauptverzeichnis der Webanwendung gilt dabei als das Dokumentenverzeichnis. 

Alle Dateien in diesem Verzeichnis und alle Unterverzeichnisse können über 

den Webserver abgerufen werden. Einzige Ausnahme ist das Verzeichnis WEB- 

INF. Da es sich hierbei um das Konfigurationsverzeichnis der Anwendung handelt, 

muss der Webserver den Zugriff auf dieses Verzeichnis verbieten. Standardmäßig 

sind mindestens die Verzeichnisse classes und lib vorhanden. Das classes- 

Verzeichnis alle Java-Klassen der Webanwendung und das lib-Verzeichnis enthält 

alle zusätzlich benötigten Bibliotheken in Form von JAR/ZIP-Dateien. Ebenso 

enthalten sein muss die Datei web.xml im WEB-INF-Verzeichnis. Die Datei enthält 

den so genannten Web Application Deployment Descriptor, wie in der J2EE- 

Spezifikation beschrieben. Hier werden die einzelnen Komponenten einer Webanwendung 

konfiguriert. Auf die Verwendung der Einstellungen in der web.xml- 

Datei wird in einem der folgenden Kapitel noch näher eingegangen. 

Um nun in Netbeans eine solche Webanwendung, bestehend aus den genannten 

Komponenten zu erstellen, kann ein vordefiniertes Template verwendet werden. 

Das Template erzeugt neben der benötigten Verzeichnisstruktur auch direkt die 

angesprochene Konfigurationsdatei web.xml im entsprechenden Verzeichnis. Das 

Vorgehen ist hierbei analog zu dem eben gemachten Template-Beispiel. Zuerst 

wird wieder im Projektmanager ein neues Projekt zur Aufnahme der Dateien 

angelegt und ein Filesystem als physikalischer Ablageort gemountet. Danach 

kann wieder über das Kontextmenü ADD NEW des Projektknotens ein Template 

ausgewählt werden. Das entsprechende Template WebModule findet sich im NEW 

WIZARD unter TEMPLATES/JSP & SERVLETS. 

Im folgenden Dialog ist lediglich der Name der Anwendung anzugeben und das 

Hauptverzeichnis aus den vorhandenen Filesystemen auszuwählen. Als Ergebnis 

erhält man dann die besprochenen Verzeichnisse inklusive der Steuerdatei, die 

auch schon mit ein paar Standardeinstellungen belegt ist. Hier bietet es sich an, 

das Template und die enthaltene web.xml-Datei an die eigenen Projekte anzupassen. 

Einstellungen, die in mehreren Webanwendungen verwendet werden, können 

auch direkt im Template untergebracht werden. Liegen die Templates alle in

36 


einem gemeinsam genutzten Verzeichnis, können auch die anderen Entwickler 

eines Projektteams die gleichen Templates verwenden. 

Nachdem das neue Projekt mit seinen Grundeinstellungen erzeugt wurde, kann 

direkt mit dem Entwickeln der Anwendungslogik begonnen werden. Da sowohl 

für Servlets als auch für JSP-Seiten wieder vorgefertigte Templates existieren, 

können diese auf schon gewohnte Weise dem Projekt hinzugefügt werden. 

Um als Beispiel nicht auf das beliebte Hello World-Beispiel zu verfallen, soll ein 

einfaches Ratespiel entwickelt werden. Der Benutzer muss eine Zahl zwischen 1 

und 100 erraten. Jeder Versuch wird von der Anwendung mitgezählt. Macht der 

Benutzer einen Fehlversuch, erhöht sich die Anzahl der gemachten Versuche und 

er kann einen neuen Versuch starten. Bei einem Treffer wird eine Erfolgsmeldung 

ausgegeben. Damit das Spiel nicht unendlich läuft, bricht der Server nach zehn 

Versuchen das Spiel mit einer Fehlerseite ab. 

Die Logik der Anwendung wird in einem Servlet implementiert. Dazu kann wieder 

wie gewohnt das entsprechende Template verwendet werden, um das neue 

Servlet in das Projekt aufzunehmen. Dazu ist der Knoten Classes auszuwählen 

und dort wieder über das Kontextmenü der NEW WIZARD zu starten. 

Die so erzeugte Klasse ZahlServlet besitzt durch das Template bereits alle notwendigen 

Methoden, die nun auf unsere Bedürfnisse angepasst werden müssen. 

In der generierten Klasse werden sowohl GET- als auch POST-Aufrufe an die 

Methode processRequest weitergeleitet. Dadurch muss auch nur an dieser Stelle 

die Anwendungslogik implementiert werden. 

Listing 2.3: 

Servlet für das Zahlenspielbeispiel 

import javax.servlet.*; 

import javax.servlet.http.*; 

public class ZahlServlet extends HttpServlet { 

... 

protected void processRequest( 

HttpServletRequest request, 

HttpServletResponse response) 

throws ServletException, java.io.IOException { 

String message = ""; 

String nextView = "/question.jsp"; 

HttpSession session = request.getSession(); 

NumberBean numberBean = 

(NumberBean)session 

.getAttribute("numberBean"); 

if (numberBean == null) 

numberBean = new NumberBean(); 

numberBean.inc();


} 

... 

String guess = 

(String)request 

.getParameter("number"); 

if (guess != null) { 

int number = new Integer(guess).intValue(); 

if (number == numberBean.secretNumber) { 

message = numberBean.count+""; 

nextView = "/success.jsp"; 

} 

else if (number < numberBean.secretNumber) 

message = number + " ist zu niedrig." 

+ "Versuchen Sie es erneut."; 

else if (number > numberBean.secretNumber) 

message = number + " ist zu hoch." 

+ "Versuchen Sie es erneut"; 

} 

// put values in session 

session.putValue("message", message); 

session.putValue("numberBean", numberBean); 

// call next view 

if (numberBean.count == 11) { 

nextView = "/error.jsp"; 

session.removeAttribute("numberBean"); 

} 

request 

.getRequestDispatcher(nextView) 

.forward(request, response); 

} 

class NumberBean { 

public int count = -1; 

public int secretNumber = 0; 

public NumberBean() { 

secretNumber = (int)(Math.random()*100+1); 

} 

} 

public void inc() { 

count++; 

} 

Die implementierte Logik beschränkt sich darauf, die übergebene Zahl aus dem 

Request auszulesen und mit einer in der Session gespeicherten Zahl zu vergleichen. 

Je nach dem Ergebnis des Vergleichs wird eine Nachricht in der Session abgelegt 

und anschließend über den RequestDispatcher eine JSP-Seite als Ergebnis geliefert.

38 


Die notwendigen JSP-Seiten der Anwendung können ebenfalls aus einem Template 

generiert werden. Für die Anwendung werden neben der eigentlichen Eingabemaske 

noch eine Fehlerseite und eine Erfolgsseite benötigt. 

Listing 2.4: 

JSP-Quelltext der Eingabemaske des Zahlenspiels 

 

 

Eingabemaske 

 

 

 

 

Bitte eine Zahl zwischen 1-100 eingeben 

 

 

 

 

Listing 2.5: 

JSP-Quelltext der Erfolgsseite 

 

 

JSP Page 

 

 

Herzlichen Glückwunsch 

Nach nur Versuchen haben Sie die Zahl erraten. 

 

 

Listing 2.6: 

JSP-Quelltext der Fehlerseite 

 

 

JSP Page 

 

Leider verloren. Ein neues Spiel ? 

 

 

Nachdem die JSP-Seiten erstellt wurden und die Servlet-Methoden implementiert 

worden sind, kann die Anwendung direkt in Netbeans getestet werden. Zu diesem 

Zweck wird Netbeans mit einem eingebauten JSP und Servlet Container ausgeliefert. 

In der aktuellen Version von Netbeans (3.3.2) wird dafür der aus dem Jakarta-


Projekt stammende Tomcat-Server verwendet. Die enge Kopplung an die Entwicklungsumgebung 

bringt gerade bei der Entwicklung von Webanwendungen 

starke Vereinfachungen während der Entwicklung. Zum einen können die Anwendungen 

direkt in der Umgebung gestartet und getestet werden. Zudem ist es aber 

auch möglich, die JSP-Seiten schon vor dem Deployment auf einem Servlet Container 

zu testen. 

Normalerweise werden JSP-Seiten erst beim ersten Aufruf innerhalb des Containers 

in Java Servlets umgewandelt und dann kompiliert. Dadurch werden eventuelle 

Syntax-Fehler in den JSP-Seiten auch erst zur Laufzeit der Anwendung 

bemerkt. Hier bietet Netbeans die Möglichkeit, die Übersetzung der JSP-Dateien 

genauso wie normale Java-Dateien vorzunehmen. Zum anderen kann auch das 

entstandene Java Servlet in den Editor geladen und untersucht werden. Gerade um 

Laufzeitfehler zu finden, kann das für die Fehlerdiagnose sehr hilfreich sein. 


Fertige Webanwendung in Netbeans 

Wie schon bei der im vorhergehenden Beispiel erstellten Anwendung ist auch für 

ein Servlet das Starten aus der Umgebung möglich, entweder über das Kontextmenü 

des Servlets in der Baumansicht oder über den grünen Pfeil in der Toolbar. 

Beim Starten der Anwendung wird zuerst der integrierte Tomcat-Server gestartet 

und die Anwendung installiert.

40 



Starten des Tomcat-Servers im Running Workspace 

Ist der Server gestartet, wird das Servlet über einen externen Webbrowser angesprochen 

und ausgeführt. Da der integrierte Tomcat-Server auf dem Port 8080 auf 

Anfragen wartet, wird folgende URL verwendet: http://localhost:8080/servlet/ 

ZahlServlet 


Eingabemaske für das Zahlenspiel 

Nach Eingabe der Zahl wird das Servlet erneut aufgerufen und bekommt dieses 

Mal einen Parameter mitgeschickt. Sofern die Zahl nicht richtig geraten worden 

ist und noch neue Eingaben erlaubt sind, wird wieder auf die Startseite (question.jsp) 

verzweigt. Sofern vorhanden, wird eine kurze Meldung oberhalb des 

Eingabeformulars angezeigt.



Eingabemaske inklusive Meldung 

Treten Fehler auf, kann der Debugger verwendet werden, um das Servlet, aber 

auch die JSP-Seiten schrittweise zu durchlaufen. Um die Verarbeitung innerhalb 

des Servlets anzuhalten, kann, wie gewohnt, ein Breakpoint an einer Programmzeile 

gesetzt werden. Der Debugger beendet dann an genau dieser Stelle die Verarbeitung 

und der Quelltext kann schrittweise durchlaufen werden. Um das 

Gleiche in einer JSP-Seite machen zu können, ist es möglich, im erzeugten Servlet 

einen Breakpoint zu setzen. Der Quelltext der erzeugten Servlets ist über das 

Kontextmenü der JSP-Knoten in der Baumansicht verfügbar. 

Alles in allem macht die Integration von Netbeans mit dem Tomcat-Server einen 

sehr runden Eindruck. Zur Entwicklung von Servlet- und JSP-basierten Anwendungen 

bietet Netbeans dadurch eine sehr mächtige und effiziente Umgebung an. 

Neue Funktionalitäten können ohne große Umwege direkt ausgetestet werden. 

Auch der integrierte Debugger macht die Entwicklung von Webanwendungen 

wesentlich komfortabler im Vergleich zu Umgebungen, bei denen der Servlet 

Container als eigenständige Anwendung läuft. 

GUI-Entwicklung 

Neben der Möglichkeit, Java-Quellen über den oben beschriebenen Template- 

Mechanismus zu erzeugen, bietet Netbeans für die Entwicklung grafischer Oberflächen 

noch weitergehende Funktionalitäten. Eine einfache Anwendung inklusive 

grafischer Oberfläche ist wie gewohnt über ein vorhandenes Template 

möglich. Die so erzeugte Java-Anwendung kann nach der Generierung direkt aus 

Netbeans gestartet werden und verfügt bereits über eine Menüleiste mit den gängigsten 

Menüpunkten. 

Um die Erstellung von grafischen Oberflächen zu erleichtern, verfügt Netbeans 

über einen sehr mächtigen Editor für die grafische Bearbeitung der Oberflächen. 

Diese können so ohne Programmierung rein visuell erstellt werden. Da der Editor 

lediglich Standard-Java erzeugt, kann das Ergebnis auch noch manuell nachbearbeitet 

werden. Öffnet man den Quelltext der erzeugten Klasse, sieht man bereits 

einige Stellen, an denen der Quelltext von Netbeans erstellt worden ist. Der generierte 

Quelltext kann nicht geändert werden und ist im Texteditor farblich hinterlegt. 

An den restlichen Stellen können durch den Entwickler Erweiterungen 

eingebaut werden. Dadurch kann der grafische Editor zu jeder Zeit wieder verwendet 

werden, auch wenn bereits Erweiterungen an der erzeugten Klasse vorgenommen 

worden sind.

42 


Aus der Werkzeugleiste im Forms Editor können verschiedenste grafische Oberflächenkomponenten 

auf die Form gesetzt werden. Sie müssen nur einfach die 

entsprechende Komponente in der Werkzeugleiste anwählen und anschließend 

auf der Form platzieren. Das Aussehen der Form und deren Verhalten lässt sich 

im Editor ohne Ausführen der restlichen Anwendung testen. 

In der Praxis erweist sich der Forms Editor als äußerst hilfreich. Durch den 

Zugriff auf nahezu alle Elemente der AWT- und Swing-Bibliotheken sind auch 

komplexere Oberflächen mit dem Werkzeug beherrschbar. Wie auch bei anderen 

Werkzeugen, die den Quelltext einer grafischen Oberfläche generieren, muss der 

Entwickler sich an den erzeugten Quelltext erst gewöhnen und diesen verstehen. 

Durch die Trennung des generierten Teils der Anwendung von den manuellen 

Änderungen der Entwickler treten allerdings kaum Probleme auf, wenn die Form 

nachträglich geändert werden muss. Hier unterscheidet sich der in Netbeans verwendete 

Ansatz klar von anderen Werkzeugen, wo versucht wird, beliebige Programmierstile 

zu verarbeiten. Borlands JBuilder beispielsweise wertet beim 

Starten seines Form Editors die Java-Klasse aus und versucht anhand der ermittelten 

Informationen den Editor aufzubauen. Werden starke Veränderungen vorgenommen, 

ist die Wahrscheinlichkeit recht hoch, dass der Editor nicht mehr für 

spätere Änderungen des Layouts benutzt werden kann. 

Gerade bei der recht komplexen Arbeit mit den Java Layout-Managern bietet das 

visuelle Arbeiten mit dem Netbeans Forms Editor klare Vorteile gegenüber der 

reinen Programmierung. Um das gewünschte Layout einer Anwendung zu erzielen, 

ist es häufig notwendig, Swing-Komponenten mit den unterschiedlichsten 

Layout-Managern zu schachteln. Hier hilft die Baumansicht des Forms Editors, 

der alle in einer Form enthaltenen Komponenten darstellt. Die Elemente können 

hier direkt angewählt und bearbeitet werden. So ist zum Beispiel die Auswahl des 

Layout-Managers direkt über das Kontextmenü im Baum möglich. 


Auswahl des Layout-Managers in der Baumansicht des Editors


Verwendet man Komponenten anderer Hersteller, können diese in den Editor integriert 

werden. Sie stehen dann wie die bereits vorhandenen Komponenten über 

eine Werkzeugleiste zur Verfügung und können von dort ausgewählt werden. 

Unterhalb der Baumansicht werden jeweils die Eigenschaften der ausgewählten 

Komponente angezeigt. 

Integrierter Debugger 

Gerade bei komplexen verteilten Anwendungen ist es manchmal hilfreich, 

bestimmte Stellen schrittweise durchlaufen zu können. Zu diesem Zweck steht 

der Java SDK bereits mit dem JDB (Java Debugger) ein Werkzeug zur Verfügung. 

Da es sich dabei allerdings um eine reine Kommandozeilen-Anwendung handelt, 

ist die Bedienung auch recht unhandlich. Die meisten Entwicklungsumgebungen 

bieten daher zumindest ein grafisches Frontend zur Kommandozeilen-Version an. 

Andere Umgebungen gehen noch einen Schritt weiter und bieten einen komplett 

eigenen Debugger an. Während einer Debug-Sitzung sollten zumindest die folgenden 

Funktionen zur Verfügung stehen: 

• Anzeige der aktuellen Zeile im Quelltext 

• Anzeige von Variableninhalten 

• Setzen von Unterbrechungspunkten (Breakpoint) 

Zusätzlich zu diesen Anforderungen bietet die Debugger-Oberfläche von Netbeans 

noch folgende Möglichkeiten: 

• Definition von Unterbrechungsbedingungen 

• Unterbrechung bei Exception 

• Watchlist mit Variablen, die beobachtet werden sollen 

• Anzeige des Aufrufstapels 

Besonders interessant ist die Möglichkeit, auch Webanwendungen im Debugger 

laufen zu lassen. Unterbrechungspunkte können dazu wie gewohnt an beliebiger 

Stelle gesetzt werden. Betrachtet man die in diesem Kapitel erstellte Webanwendung, 

so bietet sich als Unterbrechungspunkt die erste Zeile der process- 

Request(...)-Methode an. Dadurch wird die Beantwortung jeder Anfrage aus 

dem Webbrowser an dieser Stelle angehalten und der Debugger markiert die 

Zeile im Quelltext. Nun kann schrittweise durch die Anwendung gelaufen werden. 

Zum Setzen eines Unterbrechungspunktes wird die entsprechende Zeile ausgewählt 

und das Kontextmenü TOGGLE BREAKPOINT gewählt. Die Zeile wird 

dadurch farblich hervorgehoben und an der linken Seite des Editors mit einem 

Icon markiert.

44 



Markierter Breakpoint (Unterbrechungspunkt) in ZahlServlet 

Die so vorbereitete Anwendung kann direkt über das Menü DEBUG/START in einer 

Java Debugger-Sitzung gestartet werden. Da es sich um eine Webanwendung handelt, 

wird wieder zuerst der Tomcat-Server gestartet, zu dem sich dann der integrierte 

Debugger verbinden kann. Das Debugging erfolgt in diesem Fall über eine 

entfernte Schnittstelle der Java VM. Das verwendete Protokoll JPDA ist Teil der 

Java 2SE ab Version 1.3. Nach dem Starten der Anwendung wechselt Netbeans 

auf den Debugging Workspace, der eine Reihe von Fenstern enthält, die Informationen 

über den aktuellen Zustand der Anwendung enthalten. 

Neben der Liste der gesetzten Unterbrechungspunkte stellt ein Fenster den Aufruf-Stack 

dar, der bis zur aktuellen Position geführt hat. Ein weiteres Fenster enthält 

die so genannten Watches. Hier können Variablen beobachtet werden. Eine 

Variable wird hier einfach über ihren Namen hinzugefügt. Zur Laufzeit werden 

dann hier die Werte der aktuell verfügbaren Variablen mit diesem Namen angezeigt. 

Ist zurzeit keine im Gültigkeitsbereich verfügbar, wird kein Wert angezeigt. 

Über eine spezielle Werkzeugleiste des Debuggers kann durch die Anwendung 

navigiert werden. 


Debugger-Werkzeugleiste 

Folgende Funktionen stehen darüber zur Verfügung (von links nach rechts): 

1. START (neue Debugger-Sitzung) 

2. CONTINUE (Fortsetzen bis zum nächsten Breakpoint bzw. Ende) 

3. ATTACH (Debugger an entfernten Prozess anbinden, JPDA) 

4. FINISH (Debug-Sitzung beenden) 

5. STEP INTO (in die aufgerufene Methode verzweigen) 

6. RUN TO CURSOR (Ausführen bis zum Eingabezeichen)


7. STEP OVER (Ausführen der Anweisung) 

8. STEP OUT (Zurückspringen zum Aufrufer) 

9. TOGGLE BREAKPOINT (Unterbrechunspunkt An/Aus) 

10. ADD BREAKPOINT (neuen Unterbrechungspunkt hinzufügen) 

11. ADD WATCH... (neuen Watch hinzufügen) 


Debugging Workspace für Webanwendung 

Abbildung 2.19 zeigt die Fenster des Debugging Workspace für die Beispielanwendung. 

Neben der schon bekannten Markierung des Unterbrechungspunktes 

ist zudem noch die aktuelle Zeile, an der sich die Anwendung gerade befindet, 

grün markiert und mit einem Pfeil gekennzeichnet. Im linken Teil sind die Informationsfenster 

untergebracht, unten links zum Beispiel das Fenster mit den Variablen, 

die zurzeit beobachtet werden sollen. 

Sobald ein Variablenname aus dem aktuellen Gültigkeitsbereich mit einem der beobachteten 

Namen übereinstimmt, wird der aktuelle Wert angezeigt. Im Beispiel wird 

mit der Variablen message ein einfacher String und mit numberBean eine Instanz 

der Klasse NumberBean angezeigt. Hier wird deutlich, dass die Anzeige sich nach 

dem gefundenen Datentyp verändert. Im Fall der numberBean können deswegen 

direkt die als public deklarierten Attribute count und secretNumber angezeigt werden. 

Zusätzlich zu den erwähnten Watches zur Kontrolle von Variableninhalten besteht 

noch die Möglichkeit, einfach alle aktuellen Variablen anzuzeigen. In diesem 

Fenster werden dann jeweils alle Variablen angezeigt, die zurzeit gültig sind.

46 

Versions-/Releasemanagement-System 

2.2 Versions-/Releasemanagement-System 

Neben den bereits besprochenen Werkzeugen für die Entwicklung der Anwendungen 

werden in der Regel noch Werkzeuge und Verfahren für ein Versionsmanagement 

benötigt. Auch wenn der Einsatz von Versionsmanagement- 

Werkzeugen schon für Ein-Mann-Werkzeuge Sinn macht, ist ein Einsatz bei mehreren 

Entwicklern unverzichtbar. 

Neben der Tatsache, dass verschiedene Stände (Versionen) einer Anwendung in 

der Entwicklung sein können, besteht in der Regel auch die Anforderung, dass 

alle Entwickler zu jedem Zeitpunkt alle Quellen bearbeiten können müssen. Die 

durch dieses konkurrierende Arbeiten eventuell auftretenden Konflikte sollten 

wenn möglich vom System behandelt werden. 

Genau an dieser Stelle unterscheiden sich die gängigen am Markt verfügbaren 

Versionsmanagement-Systeme. Die einen lassen einen konkurrierenden Zugriff 

zu, andere hingegen erlauben nur einen exklusiven Zugriff auf Dateien. 

Systeme, die nur einen exklusiven Zugriff auf Dateien zulassen, vermeiden 

dadurch direkt das Auftreten von Konflikten in den Quellen. Als Nachteil fällt 

dabei auf, dass es möglich ist, andere Entwickler über längere Zeit von der Bearbeitung 

einer Datei auszuschließen, weil das Freigeben der Datei vergessen worden 

ist. In diesem Fall müsste die Datei explizit durch einen Administrator des 

Versionsmanagement-Systems freigegeben werden. 

Systeme, die einen konkurrierenden Zugriff auf die Dateien durch die Entwickler 

zulassen, müssen in der Lage sein, die auftretenden Konflikte behandeln zu können. 

Dies kann im einfachsten Fall automatisch geschehen oder in komplexeren 

Fällen durch den Entwickler. Sofern sich zwei konkurrierende Änderungen an 

einer Datei nicht auf dieselben Bereiche der Datei beziehen, können beide Versionen 

der Datei zusammengeführt werden. 

Überschneiden sich allerdings die geänderten Bereiche, können die Dateien nicht 

einfach zusammengeführt werden und ein Entwickler muss den entstandenen 

Konflikt manuell auflösen. Doch auch wenn die unterschiedlichen Änderungen 

automatisch zusammengeführt werden konnten, ist es denkbar, dass die Funktionalität 

der Anwendung dadurch ungewollt geändert worden ist. 

Das im Open Source-Umfeld am häufigsten verwendete Werkzeug zur Verwaltung 

von Versionen und Release-Ständen ist CVS (Concurrent Versions System, 

http://www.cvshome.org). Gerade im Bereich von Open Source-Projekten, die 

klassischerweise von stark verteilten Projektteams bearbeitet werden, ist ein flexibler 

Zugriff auf die Quelltexte notwendig. Auch ist es bei solchen Projekten 

sinnvoll, nicht ständig eine Verbindung zu einem Versionsmanagement-Server 

halten zu müssen.


CVS Repository 

CVS arbeitet als Client-Server-Anwendung und verwaltet auf einen zentralen 

Server alle versionierten Module. Zu diesem Zweck wird einmalig auf dem Server 

ein so genanntes Repository angelegt. Bei CVS handelt es sich dabei um ein 

einfaches Verzeichnis, in dem eine Reihe von Steuerungsdateien angelegt werden. 

Neue Module bekommen jeweils ein Unterverzeichnis unterhalb des CVS-Startverzeichnisses 

(cvs root). 

Für den Zugriff auf den CVS-Server dient ein CVS-Client. Im einfachsten Fall 

kann hier direkt die Kommandozeilen-Version von CVS verwendet werden oder 

aber eine grafische Oberfläche. Als dritte Möglichkeit bietet sich die Integration 

von CVS in die verwendete Entwicklungsumgebung an. Die in Netbeans dazu 

notwendigen Konfigurationen werden am Ende dieses Abschnitts kurz dargestellt. 

CVS ist auf einem normal konfigurierten Linux-System normalerweise direkt 

verfügbar. Alternativ kann es auch von der CVS-Webseite heruntergeladen und 

installiert werden. Die folgenden Beispiele gehen davon aus, dass sich ein funktionsfähiges 

CVS auf dem System befindet. 

Nachdem CVS auf dem Server installiert worden ist, kann das Repository angelegt 

und initialisiert werden. Dazu muss zuerst ein Verzeichnis dafür angelegt 

werden. Das Anlegen des Repository erfolgt mit dem CVS-Kommandozeilen- 

Werkzeug mit folgenden Parametern: 

cvs –d /opt/var/cvsroot init 

Hiermit wird das Verzeichnis /opt/var/cvsroot als Repository initialisiert. Als erstes 

Unterverzeichnis wird durch das init-Kommando das Verzeichnis CVSROOT 

angelegt. In diesem Verzeichnis werden alle Konfigurationsdateien dieses Repository 

abgelegt. Da es sich ebenfalls schon um ein CVS-Modul handelt, kann nicht 

direkt auf die Dateien in diesem Verzeichnis zugegriffen werden. Alle Änderungen 

müssen – wie bei allen anderen Modulen – im Repository über die CVS- 

Client-Anwendung erfolgen. 

Der CVS-Server muss jetzt nur noch entsprechend konfiguriert werden, um auf 

das Repository zugreifen zu können. Grundsätzlich existiert für Client und Server 

nur eine ausführbare Anwendung. Auf einem Linux-Server beispielsweise wird 

der Zugriff auf das Repository über den Inet-Deamon gesteuert. Wie auch bei 

anderen Protokollen wie etwa FTP oder Telnet wartet hier der Inetd-Prozess auf 

eingehende Anfragen an definierten IP-Ports und leitet sie dann an ihm bekannte 

Anwendungen weiter. 

Auf einem Linux-System mit installiertem Inet-Daemon muss die Datei /etc/ 

inetd.conf um folgende Zeile ergänzt werden: 

2401 stream tcp nowait root /usr/local/bin/cvs 

cvs -f --allow-root=/opt/var/cvsroot pserver

48 


Alle TCP-IP-Anfragen, die auf dem Port 2401 eingehen, werden an die Kommandozeilen-Version 

von CVS auf diesem Server weitergleitet. Außerdem ist das zu 

verwendende Repository anzugeben. Die letzte Option (pserver) gibt an, dass der 

CVS-Serverprozess eine Passwort-Abfrage an den Client schicken wird. Auf 

einem Linux-System besteht hier die Möglichkeit, entweder die vorhandenen 

Systembenutzer zu verwenden oder aber neue CVS-Benutzer anzulegen. 

Eine weitergehende Behandlung der Konfiguration eines CVS-Servers findet sich 

in der offiziellen Dokumentation zu CVS unter http://www.cvshome.org/docs/ 

manual. Die Konfiguration sollte einem erfahrenen Administrator überlassen 

werden, um nicht ungewollte Hintertüren in das Linux-System einzubauen. 

Zugriff auf das Repository 

Um nun auf die Module im CVS-Verzeichnis zugreifen zu können, ist eine CVS- 

Client-Anwendung erforderlich. Standardmäßig kann auch zu diesem Zweck das 

schon als Server-Prozess verwendete Kommandozeilen-Werkzeug verwendet 

werden. 

Damit klar ist, auf welchem Server sich das Repository befindet und mit welcher 

Verbindungsmethode darauf zugegriffen werden kann, ist eine Umgebungsvariable 

vor der Verwendung von CVS zu setzen. 

Die Variable CVSROOT hat folgenden Aufbau: 

:[pserver | local]:username@hostname:cvs_root_dir_on_server 

Für den Zugriff auf den vorher konfigurierten Linux-Server ist die Variable wie 

folgt zu besetzen: 

:pserver:deicksta@cvs.deicon.de:/opt/var/cvsroot 

Da es sich in diesem Fall um einen Server mit Authentifizierung handelt, muss 

sich der Benutzer vor der Verwendung von CVS am Server anmelden. Das 

geschieht über das Kommando login auf der Kommandozeile: 

cvs login 

Sobald der Benutzer sich einmal am Server angemeldet hat, ist kein weiteres Einloggen 

in den Server mehr notwendig. Erst wenn die CVSROOT-Variable geändert 

wird, muss sich erneut gegen den Server authentifiziert werden. Der CVS-Client 

speichert dazu eine verschlüsselte Version des Passworts in einer versteckten 

Datei im HOME-Verzeichnis des Benutzers. 

Arbeiten mit CVS 

Um die Arbeitsweise mit CVS darzustellen, ist es am einfachsten, einen üblichen 

Arbeitsablauf anhand eines kleinen Beispiels durchzugehen. Dabei können dann 

die notwendigen Arbeitsschritte während der Entwicklung mit CVS dargestellt 

werden.


Da die Verwendung der Kommandozeile für den alltäglichen Gebrauch etwas 

mühselig werden kann, sollte in der Regel eine grafische Oberfläche für den 

Zugriff auf das CVS Repository verwendet werden. Wie bereits erwähnt, existieren 

hier verschiedene reine CVS-Client-Anwendungen. Für die Verwendung auf 

einem Windows-Rechner steht mit WinCVS (http://www.wincvs.org) eine sehr 

komfortable und stabile Umgebung zur Verfügung. WinCVS bietet sich auch 

dann als das passende Werkzeug an, wenn neben den Java-Quelldateien noch 

andere Dateien versioniert werden sollen. Häufig werden beispielsweise Word- 

Dokumente, Grafiken und andere Dateien zu einem Projekt mitabgespeichert, die 

nicht direkt mit der Programmentwicklung in Zusammenhang stehen. 

Während der Entwicklung ist es allerdings wünschenswert, wenn die verwendete 

Entwicklungsumgebung auch direkt mit CVS-Verzeichnissen arbeiten kann. Netbeans 

bietet genau diese Integration, ohne zusätzliche Module installieren zu 

müssen. 

Grundsätzlich wird während der Arbeit mit CVS nicht direkt im Repository gearbeitet, 

sondern in einer lokalen Kopie der Dateien. Dadurch ist nur für den 

Abgleich mit dem Repository eine Verbindung notwendig. Diese muss aber nicht 

dauerhaft zur Verfügung stehen, um etwa Dateien zu sperren oder freizugeben. 

Bevor mit der Arbeit begonnen werden kann, ist die lokale Arbeitskopie zu erzeugen. 

Dazu werden die Dateien aus dem Repository in ein lokales Verzeichnis 

kopiert. Das Verzeichnis bekommt den Namen des CVS-Moduls. 

In Netbeans werden CVS-Verzeichnisse ähnlich behandelt wie einfache Filesysteme. 

Sie müssen ebenfalls vor der Verwendung in die Oberfläche gemountet 

werden. Sofern gewünscht, kann dabei gleichzeitig ein Modul aus dem Repository 

als lokale Arbeitskopie kopiert oder aber auch eine bereits vorhandene verwendet 

werden. Über das Kontextmenü im Filesystem-Browser wird der 

entsprechende Wizard gestartet. 


Mount eines CVS-Verzeichnisses in Netbeans 

Im ersten Schritt wird das Verzeichnis angegeben, unter dem alle CVS-Module 

kopiert werden sollen. Hier wird ein bereits bestehendes Verzeichnis erwartet, das 

aber auch über den Browser-Dialog direkt angelegt werden kann. 

Als nächsten Schritt müssen die Verbindungsparameter (CVSROOT) für den CVS- 

Server angegeben werden.

50 



CVSROOT konfigurieren in Netbeans 

Nachdem hier die schon bekannten Einträge aus der Umgebungsvariablen CVSROOT 

übernommen wurden, wird im nächsten Schritt das zu verwendende CVS-Kommandozeilen-Werkzeug 

angegeben. Netbeans geht davon aus, dass der entsprechende 

Client bereits auf dem System installiert worden ist und verwendet werden kann. 

Um nun eine neue Arbeitskopie aus dem Repository zu kopieren, ist im folgenden 

Dialog noch ein Haken zu setzen. 


Anlegen der Arbeitskopie


Als letzter Schritt ist noch der Modulname einzugeben, der als Arbeitskopie 

erzeugt werden soll. 


Modulnamen auswählen 

Nach dem erfolgreichen Kopieren des CVS-Moduls in das lokale Arbeitsverzeichnis 

steht diese Arbeitskopie in Netbeans als normales Filesystem zur Verfügung. 

Zusätzlich werden an den Dateiknoten weitere Informationen angezeigt. 

Hierdurch kann direkt abgelesen werden, ob eine Datei beispielsweise lokal geändert 

worden ist oder ob nach dem Auschecken aus dem Repository noch keine 

Änderungen vorgenommen worden sind. Netbeans gleicht die Dateien in definierbaren 

Abständen mit dem CVS-Server ab und aktualisiert die angezeigten Informationen 

entsprechend. Netbeans ruft dafür das CVS-Kommando status auf. 

Dadurch ist es möglich, nicht nur lokale Veränderungen der Datei zu erkennen, 

sondern auch, ob bereits eine neuere Version von einem anderen Entwickler in 

das CVS-Repository eingecheckt worden ist. 

Bei der Arbeit mit Dateien, die in einem CVS-Server versioniert werden, sind 

eine Reihe von Dingen zu beachten. Durch die Möglichkeit der Entwickler, auf 

alle Dateien auch nicht exklusiv zugreifen zu können, ist es theoretisch denkbar, 

dass sich überschneidende Änderungen ergeben. 

Zur Verdeutlichung der generellen Arbeitsweise gehe ich im Folgenden davon 

aus, dass Entwickler A und Entwickler B gemeinsam an einem kleinen Software- 

Projekt arbeiten. Im ersten Schritt soll der Idealfall bei der Entwicklung aufgezeigt 

werden, im nächsten dann auf die möglichen Konflikte und deren Lösung 

eingegangen werden. 

Arbeiten mehrere Entwickler zugleich an ein und demselben CVS-Modul, ist die 

beste Möglichkeit, um Konflikte zu vermeiden, dass alle Entwickler klar voneinander 

getrennte Bereiche bearbeiten. Im Fall von Java-Projekten bieten sich für 

eine solche Aufteilung der Arbeitspakete die Aufteilung der Entwickler auf unterschiedliche 

Packages an. Allein durch diese Aufteilung werden in aller Regel die 

meisten Probleme mit überschneidenden Änderungen verhindert. Allerdings lassen 

sich in der Realität nicht alle Packages auch den einzelnen Arbeitspaketen

52 


zuordnen. Neben reinen Basisfunktionalitäten, die in allen Bereichen verwendet 

werden, ist es häufig auch notwendig, kleinere Änderungen an Klassen aus anderen 

Packages vorzunehmen. 

Nachdem dem Entwickler eine lokale Arbeitskopie zur Verfügung steht, wiederholen 

sich während der Arbeit die folgenden Arbeitsschritte: 

• Update des Moduls 

• Editieren ausgewählter Dateien 

• Commit des Moduls 

Im ersten Schritt wird die lokale Kopie des Entwicklers der des Repository angeglichen. 

Konkret werden alle Änderungen, die bereits von anderen Entwicklern 

an dem Modul vorgenommen und in das Repository übernommen worden sind, in 

die lokale Kopie übernommen. Sofern es sich um Änderungen in unabhängigen 

Bereichen der Dateien handelt, werden diese mit der lokalen Arbeitskopie zusammengeführt. 

Dieser Vorgang läuft automatisch ab und ist lediglich an den Ausgaben 

von CVS zu erkennen. 

Nach einem erfolgreichen Update liegen nun die neuesten Quellen aus dem Repository 

im lokalen Verzeichnis des Entwicklers. Jetzt können Sie mit der Arbeit an 

den Dateien beginnen. Sollten sich die Änderungen über einen größeren Zeitraum 

hinziehen, ohne dass man seine Änderungen als stabil in das Repository einpflegen 

möchte, können zwischendurch durch erneute Update-Vorgänge die neuesten 

Dateien der anderen Entwickler in das lokale Verzeichnis geholt werden. 

Sobald der Entwickler mit seinen Änderungen zufrieden ist, können diese wieder 

in das CVS-Repository als neue Version geschrieben werden. Zu diesem Zweck 

kann wahlweise das gesamte Modul oder nur Teilbereiche des Moduls über das 

CVS-Kommando Commit im Repository aktualisiert werden. 

Konflikte 

Der im vorangegangen Abschnitt dargestellte Arbeitsablauf mit Quelldateien in 

einem CVS-Repository stellt bisher den idealen Ablauf dar. In der Realität wird 

es allerdings ab und an zu Konflikten kommen, die nicht automatisch durch CVS 

behoben werden können. Konflikte können immer dann auftreten, wenn mindestens 

zwei Entwickler an ein und derselben Datei arbeiten. 

Angenommen, beide Entwickler holen sich ihre lokale Arbeitskopie zum gleichen 

Zeitpunkt aus dem Repository. Dadurch liegen beiden zu Beginn der Arbeit 

jeweils die aktuellen Versionen des Repository zur Bearbeitung vor. Beide beginnen 

mit der Arbeit an der gleichen Datei. Da der erste Entwickler nur eine sehr 

kleine Änderung einbaut, ist er mit der Arbeit an dieser Datei schneller fertig als 

der zweite Entwickler. Um die neue, geänderte Datei so schnell wie möglich den 

anderen Entwicklern zur Verfügung zu stellen, führt der erste Entwickler direkt 

nach seinen Änderungen ein CVS Commit auf der Datei aus.


Der zweite Entwickler führt nun eine Reihe von Änderungen an derselben Datei 

aus, die mehr Zeit in Anspruch nehmen als die des ersten Entwicklers. Nachdem 

er seine Änderungen getestet hat, versucht er die nun geänderte Datei in das 

Repository zu schreiben. Das dazu gestartete CVS Commit-Kommando scheitert 

allerdings mit einer Fehlermeldung. Anhand der Fehlermeldung erkennt der Entwickler 

nun, dass sich die Version im Repository von der unterscheidet, auf der er 

seine Änderungen gemacht hat. Bevor ein Commit möglich ist, ist daher erst ein 

Update durchzuführen, um die neuen Änderungen aus dem Repository in die 

lokale Version zu übernehmen. Das CVS-Update führt nun die Datei im Repository 

mit der Datei im lokalen Verzeichnis des Entwicklers zusammen. Wichtig ist 

dabei, dass alle lokalen Änderungen beibehalten werden. 

Wurden nun von beiden Entwicklern Änderungen in den gleichen Bereichen der 

Datei vorgenommen, kommt es beim Update zu einem Konflikt. CVS weist in 

seiner Ausgabe durch eine Fehlermeldung auf diesen Konflikt hin und markiert 

die betreffenden Stellen in der Datei mit einem speziellen Kommentar der Form: 

>>>>> 

Alter Text 

 

Da die gemachte Änderung nicht automatisch übernommen werden konnte, ist es 

nun die Aufgabe des Entwicklers, zu entscheiden, welche der Textpassagen die 

korrekte ist. Zu diesem Zweck ist es eventuell notwendig, sich mit dem Kollegen, 

der die Änderung vorgenommen hat, abzustimmen. Die Datei ist nun so zu 

ändern, dass nur noch die korrekte Textpassage vorkommt. Das Ergebnis wird 

dann über CVS Commit als neue Version in das Repository übernommen. 

2.3 Automatische Build-Umgebung 

Während der Entwicklung sind in den vorangegangenen Werkzeugen die unterschiedlichsten 

Aufgaben immer wieder zu wiederholen, um Teile der Anwendung 

zu testen. Für den Test einer Webanwendung mit Java Server Pages, an deren 

Komponenten mit mehreren Entwicklern über einen CVS-Server gearbeitet wird, 

sind zumindest folgende Schritte zum Testen auszuführen: 

1. CVS-Update auf die lokale Arbeitskopie (Änderungen anderer Entwickler) 

2. Übersetzen der Java-Klassen 

Sofern nur Teilbereiche der Anwendung getestet werden sollen, kann dies wie 

bereits beschrieben direkt in der Netbeans-Umgebung geschehen, sodass hierfür 

keine weiteren Arbeitsschritte notwendig sind.

54 

Automatische Build-Umgebung 

Sobald die komplette Anwendung in einer realen Server-Umgebung getestet werden 

soll, sind weitere Arbeitsschritte auszuführen. Für eine Webanwendung auf 

Basis des Java Servlets und Java Server Pages Containers Tomcat sind zusätzlich 

zu den genannten noch folgende Schritte notwendig: 

1. Erzeugen eines WAR-Archivs der Webanwendung 

2. Kopieren des Archivs in das webapps-Verzeichnis des Tomcat-Servers 

3. Neustart des Servers 

Dieser Vorgang wird im Allgemeinen als Deployment bezeichnet. Um eine Webanwendung 

auf dem Tomcat-Server zu deployen, wird eine so genannte WAR- 

Datei in ein spezielles Deployment-Verzeichnis des Servers kopiert. Alle WAR- 

Archive, die sich beim Start des Tomcat-Servers in diesem Verzeichnis befinden, 

werden automatisch als Anwendung deployed. Der Inhalt einer WAR-Datei ist 

durch die Sun J2EE-Spezifikation standardisiert. Wie bereits erwähnt, enthält die 

Datei mindestens die Datei web.xml. Hierbei handelt es sich um den so genannten 

Deployment Descriptor, aus dem der Tomcat-Server dann die Informationen über 

die Anwendung entnimmt. 

Ändert man nur einfache Klassen der Anwendung, ist es nicht unbedingt notwendig, 

die komplette Anwendung neu als WAR-Archiv zu deployen. Es reicht unter 

Umständen auch aus, einfach die neuen Klassen in das entsprechende Verzeichnis 

des Servers zu kopieren. 

Betrachtet man die notwendigen Arbeitsschritte, wird recht schnell die Frage aufkommen, 

wie sich diese weitestgehend automatisieren lassen können. Als eine 

erste, naheliegende Lösung kommt der Einsatz einer einfachen Batch-Datei 

infrage. Alle notwendigen Schritte könnten hier in einem Script zusammengefasst 

werden. Einer der Nachteile eines solchen Vorgehens ist, dass man sich auf eine 

Plattform festlegen oder aber direkt verschiedene Plattformen durch unterschiedliche 

Scripts unterstützen muss. 

Aus diesem Grund existieren gerade für die Entwicklung von Software verschiedenste 

Werkzeuge für die Automatisierung solcher Aufgaben. Das wohl bekannteste 

und in der Open Source-Gemeinde am häufigsten genutzte Werkzeug ist 

Make oder Gnu Make. Das Werkzeug findet sich allerdings fast hauptsächlich in 

Open Source-Projekten in C/C++. Auch kommerzielle C/C++-Entwicklungsumgebungen 

verwenden Make oder Make-ähnliche Werkzeuge als Grundlage. 

Im Bereich von Open Source Java-Projekten findet sich dagegen vermehrt ANT 

anstelle von Make. Bei ANT handelt es sich wieder um ein Teilprojekt des Apache 

Jakarta-Projektes und es ist wie die anderen Teilprojekte dort zu 100% in Java 

implementiert. 

Wie bereits bei Make wird pro Projekt eine Steuerdatei erstellt, die das eigentliche 

Script enthält. In dieser Steuerdatei oder auch Build-Datei werden die Arbeitsschritte 

und deren Abhängigkeiten mithilfe einer XML-Syntax beschrieben.


Durch die Verwendung von Java und XML sind die Scripts auf allen Plattformen 

ausführbar, auf denen Java verfügbar ist. Entwickler, die auf unterschiedlichen 

Plattformen entwickeln, können trotzdem die gleiche Arbeitsweise verwenden 

und für den automatisierten Prozess ANT einsetzen. 

Wie in Make auch, können den Arbeitsschritten innerhalb eines Projektes Abhängigkeiten 

zugewiesen werden. Ein Beispiel wäre, das WAR-Archiv erst zu erstellen, 

wenn die neuesten Klassen erzeugt worden sind. Tritt bei der Erzeugung der 

Klassen nun ein Fehler auf, wird auch der davon abhängige Arbeitsschritt nicht 

mehr ausgeführt, sondern eine Fehlermeldung ausgegeben. 

Die bereits vorhandenen Funktionalitäten von ANT können über eine Java API 

auf einfache Weise erweitert werden. Diese Schnittstelle wird immer mehr auch 

von Anbietern kommerzieller Applikationsserver benutzt, um den Deploymentvorgang 

auf Ihrem Server mit ANT zu ermöglichen. Arbeiten, für die normalerweise 

eine grafische Oberfläche des Anbieters verwendet werden muss, sind dann 

direkt in die ANT-Scripts einbaubar. 

Doch nicht nur kommerzielle Anbieter erweitern auf diesem Weg ANT. Es 

finden sich immer wieder Entwickler, die Erweiterungen für ANT ebenfalls als 

Open Source anbieten. Sollte sich eine benötigte Funktion dennoch nicht finden 

und möchte man diese auch nicht selber herstellen, kann zur Not auch aus 

einem ANT-Script eine externe Anwendung über das Betriebssystem gestartet 

werden. 

2.3.1 ANT-Syntax 

Beim Starten versucht ANT das zu verwendende ANT-Script im aktuellen Verzeichnis 

zu finden. Sofern nicht beim Start eine andere Datei als Script angegeben 

worden ist, wird nach einer Datei mit dem Namen build.xml gesucht. Sollte diese 

nicht vorhanden sein, kann ANT über einen Startparameter veranlasst werden, die 

Datei auch in den übergeordneten Verzeichnissen zu suchen. In diesem Fall werden 

bis zum Hauptverzeichnis alle Verzeichnisse nach der Datei durchsucht. 

Listing 2.7: 

Einfaches ANT-Script 

 

 

 

 

 

 

56 


 

 

 

 

 

 

 

 

Jedes ANT-Script enthält genau einen project-Tag, der als Attribut den Namen 

des Projektes und das Basisverzeichnis enthält. Unterhalb dieses Tags liegen die 

verschiedenen Arbeitsschritte in Form von target-Tags. Zusätzlich können innerhalb 

eines ANT-Scripts auch Variablen mit Werten belegt werden. Dazu dient der 

property-Tag. Die so definierten Properties können an beliebiger Stelle als Platzhalter 

eingesetzt werden. Zur Laufzeit werden die entsprechenden Stellen dann 

mit den aktuellen Werten der Variablen ersetzt. 

Wie im Beispiel zu sehen, werden die so definierten Variablen über eine spezielle 

Syntax referenziert, angefangen mit dem $-Zeichen und eingeschlossen in 

geschweiften Klammern (${propertyname}). 

Einzelne Aufgaben werden in ANT-Scripts auf so genannte Targets verteilt. Beim 

Ausführen des Scripts können diese dann direkt aufgerufen werden. Wie auch in 

Make-Scripts üblich, bestehen zwischen den Targets Abhängigkeiten. Sobald ein 

Target von einem anderen abhängt, wird das entsprechende Target zuerst ausgeführt. 

Im oben gezeigten Beispiel-Script ist es für das Ausführen des Targets compile 

notwendig, das Ausgabeverzeichnis über das Target init zu erzeugen. 

 

Innerhalb der Targets werden die eigentlichen Aufgaben (task) ausgeführt. Als 

Teil der ANT-Umgebung finden sich bereits eine Vielzahl von vordefinierten 

Tasks. Zusätzlich existieren eine Reihe von optionalen Tasks, die für speziellere 

Aufgaben entwickelt worden sind. Werden für ganz spezifische Aufgaben in 

einem Projekt neue Funktionalitäten benötigt, können zu diesem Zweck neue 

ANT-Targets entwickelt werden. Es ist möglich, jederzeit über das ANT-Target 

exec eine externe Anwendung aufzurufen und dadurch Funktionalitäten zu verwenden, 

die nicht über ANT direkt verfügbar sind. Da man sich dadurch allerdings 

für eine spezielle Umgebung festlegt, sollte darauf weitestgehend verzichtet 

werden. Möchte man die ANT-Scripts möglichst unabhängig vom Betriebssystem 

halten, sollte in solchen Fällen lieber eine eigene ANT-Task in Java realisiert werden.


Bei der Arbeit mit Dateien, die sich in stark verschachtelten Verzeichnissen befinden, 

bietet ANT einen sehr flexiblen und mächtigen Mechanismus. Über so 

genannte FileSet-Strukturen können Muster auf Verzeichnisse angewandt werden. 

Sollen beispielsweise alle Dateien mit der Endung .xml in eine Jar-Datei aufgenommen 

werden, die irgendwo unterhalb eines Verzeichnisses liegen, kann die 

folgende Task verwendet werden. Die Datei web.xml, die sich ebenfalls in einem 

Unterverzeichnis befindet, soll nicht mit in das Archiv aufgenommen werden. 

Listing 2.8: 

Anwenden von FileSet-Strukturen zur Dateiauswahl 

 

 

 

 

 

 

FileSets können in nahezu allen Tasks verwendet werden, um die Dateien auszuwählen. 

Bei der Definition der Suchmuster in den eingebetteten include/exclude- 

Tags ist wieder eine spezielle Syntax verwendet worden, um beliebige Unterverzeichnisse 

einzuschließen. Beim Auswerten der Muster werden die doppelten 

Sternchen (**) mit allen Unterverzeichnissen ersetzt. Im konkreten Beispielmuster 

werden daher alle Dateien in das Archiv aufgenommen, die die Endung .xml 

haben und die sich in irgendeinem Unterverzeichnis von ${xml.dir} befinden. 

Ausgenommen davon ist lediglich die Datei web.xml, die sich in einem Unterverzeichnis 

von ${xml.dir}/webapps befindet. 

2.3.2 Installation und Verwendung 

Nach dem Download des Archivs von der Jakarta-Webseite (http://jakarta.apache.org/ant) 

kann der Inhalt in ein beliebiges Verzeichnis ausgepackt werden. 

ANT besteht zum einen aus einer Reihe von Java-Archiven mit den ANT-Klassen 

und den Standard-Targets. Daneben liegen im bin-Verzeichnis noch einige Startscripts 

für verschiedene Plattformen. Aufgabe dieser Scripts ist das Setzen der 

richtigen Umgebungsvariablen wie JAVA_HOME und CLASSPATH für ANT. Um auf 

diese Dateien zugreifen zu können, sollte das Verzeichnis in den allgemeinen 

Suchpfad aufgenommen werden. Dazu ist die PATH-Umgebungsvariable unter 

Windows um dieses Verzeichnis zu erweitern. 

Unter Windows dient dann das Batch-Script %ANT.Verzeichnis%\bin\ant.bat 

zum Starten von ANT. Nach erfolgreicher Installation und Anpassung der PATH- 

Variablen liefert das folgende Kommando die aktuelle ANT-Version: 

C:\ ant –version 

Ant version 1.4.1 compiled on November 20 2001 

C:\

58 


Um ein ANT-Script auszuführen, wird zunächst in das Projektverzeichnis 

gewechselt, in dem sich die Datei build.xml befindet. Mit dem folgenden Kommando 

wird nun ANT gestartet und das Default-Target wie im project-Tag definiert 

ausgeführt. 

C:\develop\projekt1> ant 

Soll explizit ein spezielles Target ausgeführt werden, kann der Name an das 

Batch-Script als Parameter übergeben werden. Idealerweise existieren in allen 

Build-Scripts, die in einem Projektteam verwendet werden, eine Reihe von Standard-Targets. 

Kandidaten für solche Standards sind zum Beispiel das Target 

clean, um die Ergebnisse vorangegangener Build-Vorgänge komplett zu löschen. 

Auch compile zum Übersetzen der Quelldateien und jar zum Erstellen eines Java- 

Archivs sind gängige Targets, die sich häufig in ANT-Scripts finden. 

Während die einzelnen Arbeitsschritte abgearbeitet werden, erzeugt ANT eine 

Reihe von Ausgaben, die über den Fortschritt innerhalb des Scripts informieren. 

Treten während eines Arbeitsschrittes Fehler auf, so wird der Build-Prozess an 

dieser Stelle unterbrochen und eine entsprechende Fehlermeldung ausgegeben. 

Diese Fehlermeldung stammt in der Regel von der ausgeführten Task. Werden 

beispielsweise über die Task javac die Java-Quelldateien übersetzt und treten 

dabei Syntaxfehler auf, werden die jeweiligen Java-Compilerfehler ausgegeben. 

Anschließend wird die Verarbeitung des Scripts abgebrochen. 

2.3.3 Integration in IDE-Umgebungen 

Als einer der Vorteile, die für die Verwendung von ANT spricht, ist die Plattformunabhängigkeit 

der Scripts. Ein weiterer Vorteil ergibt sich aus der Tatsache, dass 

mit dem Build-Script für ANT für jeden Entwickler eines Teams eine Umgebung 

zur Verfügung steht, mit der alle notwendigen Arbeitsschritte vorgenommen werden 

können. Es ist also nicht vorgegeben, welche integrierte Entwicklungsumgebung 

im Team eingesetzt werden muss. Jeder Entwickler kann zur Entwicklung 

jedes beliebige Werkzeug verwenden, solange das ANT-Script für die darin definierten 

Prozesse genutzt wird. 

Zudem ist es dadurch auch möglich, einfache Texteditoren für die Entwicklung zu 

verwenden, die keine Integration der Java SDK-Werkzeuge bieten. Die hier 

besprochenen integrierten Entwicklungsumgebungen JEdit und Netbeans verfügen 

über eine sehr komfortable Integration von ANT Build-Scripts. Für beide 

Umgebungen existieren Erweiterungen, die ANT-Scripts lesen und ausführen 

können. Die Verwendung ist in beiden Werkzeugen recht ähnlich. Zum Erstellen 

von ANT-Scripts bietet jEdit zudem noch eine Reihe von nützlichen Werkzeugen 

wie etwa das automatische Vervollständigen von Tagnamen und das dialoggestützte 

Eingeben von Attributen der Tags. Dieser Dialog ist immer dann hilfreich, 

wenn man sich beim Erstellen eines Scripts nicht mehr sicher ist, welche Attribute 

eines Tags zwingend sind und welche nur optional.


In JEdit werden ANT-Scripts über das Plug-In AntFarm integriert. Wie auch die 

anderen Plug-Ins lässt sich AntFarm an beliebiger Stelle in die grafische Oberfläche 

integrieren. Da kein direkter Bezug zu einem Projekt in JEdit besteht, werden 

im AntFarm-Plug-In immer alle ihm bekannten ANT-Scripts angezeigt. Wird die 

Zahl der Scripts zu hoch, wird die Sache dadurch etwas unübersichtlich. Bei einer 

überschaubaren Anzahl von Scripts kann das aber auch von Vorteil sein, da man 

nicht mehr zwischen Projekten wechseln muss, um mal eben eine andere Anwendung 

zu compilen. Grundätzlich wäre aber eine etwas bessere Unterteilung der 

Anzeige dieses Plug-Ins wünschenswert. 


ANT-Integration in JEdit 

Das AntFarm-Plug-In markiert das Default-Target eines Build-Scripts anhand 

eines grünen Häkchen. Zum Ausführen ist es ausreichend, den entsprechenden 

Knoten in der Baumansicht auszuwählen und doppelt anzuklicken. Wird ANT 

zum ersten Mal aus dem Plug-In gestartet, hat man noch die Wahl zu entscheiden, 

ob ANT als externer Prozess über die bereits erwähnte Batch-Datei gestartet werden 

soll oder innerhalb der JVM von JEdit. Leider werden aber gerade im zweiten 

Fall die Muster von FileSet-Tags nicht korrekt ausgewertet, was unter Umständen

60 


zu seltsamen Ergebnissen führen kann. Die Ausgaben von ANT werden in der 

Konsole angezeigt. Hier zeigt sich auch gleich noch ein interessanter Aspekt der 

Plug-In-Architektur von JEdit. Da es sich bei der Konsole ebenfalls um ein Plug- 

In handelt, ist es möglich, zwischen den Plug-Ins Informationen auszutauschen. 

Plug-Ins haben also nicht nur Zugriff auf die Basiskomponenten von JEdit, sondern 

sind auch in der Lage, Funktionalitäten bereits installierter Plug-Ins zu verwenden 

und damit eventuell zu erweitern. 

Treten während der Abarbeitung des Scripts Fehler auf, erscheinen diese wiederum 

in der ErrorList. Je nach Fehlertyp lässt sich von dort über einen Doppelklick auf die 

Fehlermeldung direkt an die fehlerhafte Stelle in der Quelldatei springen. 

Wie bereits erwähnt, bietet JEdit noch ein weiteres nützliches Werkzeug für die 

Arbeit mit ANT-Scripts. Während der Erstellung einer build.xml-Datei können 

die eingegebenen Tags automatisch erweitert oder die Attribute über einen Eingabedialog 

besetzt werden. Die Unterstützung geht sogar so weit, dass Tags automatisch 

geschlossen werden, sobald der Beginn eines Ende-Tags (



Tag-Dialog in JEdit mit vorbelegter Auswahl für refid-Attribut 

In Abbildung 2.26 wird der Editor für den Tag path angezeigt. Im oberen Teil sind 

alle definierten Attribute zu sehen inklusive des XML-Typen. Das Attribut refid 

dient dazu, einen definierten Pfad oder ein FileSet über dessen ID zu referenzieren. 

Hier werden bereits alle definierten IDs in der Auswahlliste angezeigt. Eine 

Eingabe ist hier nicht mehr notwendig. Im unteren Teil des Dialogs sieht man 

direkt den resultierenden Tag, wie er in das Build-Script eingefügt wird. 

Für die Integration in Netbeans steht ein Modul zur Verfügung, das bereits in der 

Standardinstallation vorhanden ist. Sobald die Datei build.xml in einem Filesystem 

erkannt wird, wird diese direkt als ANT-Script behandelt und bekommt ein 

besonderes Icon in der Baumansicht. Beim Aufklappen des Knotens werden die 

enthaltenen Elemente der Build-Datei angezeigt. Im Gegensatz zum AntFarm- 

Plug-In von JEdit werden nicht nur die ausführbaren ANT-Targets angezeigt, sondern 

einfach alle vorhandenen Knoten unterhalb des project-Knotens. Grundsätzlich 

wird die Datei wie eine beliebige XML-Datei mit all ihren Knoten als Baum 

dargestellt. In der Baumansicht können die einzelnen Elemente auch editiert werden. 

Soll beispielsweise ein Attribut eines Knotens angepasst werden, kann dieser 

direkt im Baum ausgewählt und über das Kontextmenü der Eigenschafteneditor 

gestartet werden.

62 

Fazit 


Editor für Tag-Attribute 

2.4 Fazit 

Allerdings werden über diesen Weg nicht wie in jEdit die zwingend notwendigen 

Attribute besonders hervorgehoben. Für das schnelle Erstellen von ANT-Scripts 

erscheint mir dieser Weg daher auch etwas zu umständlich. Hier ist die Unterstützung 

in jEdit eher eine Hilfe bei der Erstellung. 

Gestartet werden die ANT-Targets wie bereits in jEdit durch einen Doppelklick in 

der Baumansicht. Auch die Ausgaben von ANT werden in einem separaten Fenster 

angezeigt, von dem im Fehlerfall direkt an die Fehlerstelle gesprungen werden 

kann. Da ANT innerhalb der Java VM von Netbeans gestartet wird und nicht wie 

bei jEdit in einem externen Prozess, sind die Antwortzeiten in Netbeans spürbar 

besser. 

Gerade im Bereich der Entwicklungsumgebungen finden sich sehr ausgereifte 

Open Source-Produkte, die zum Teil mehr als eine Alternative zu kommerziellen 

Umgebungen darstellen. Gerade Netbeans wartet mit einer Fülle an Funktionalitäten 

und möglichen Erweiterungen auf, die man so nur schwer in einem kommerziellen 

Werkzeug finden wird. Ein weiterer Vorteil von Netbeans ist zum 

einen die Erweiterbarkeit auf die eigenen Anforderungen, zum anderen aber auch 

die Möglichkeit, Netbeans als Basis für eigene Anwendungen zu verwenden. 

Durch die Kombination der einzelnen freien Werkzeuge wie etwa Netbeans, CVS 

und Tomcat erhält man eine sehr durchgängige und leistungsfähige Umgebung, 

die stark an die eigenen Systeme angepasst werden kann.

Leseprobe

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?