Das innovative Eclipse-Konzept weitgehend unabhängiger Plugins beschäftigt seit über zwei Jahren die Welt der Software-Entwicklung. Grund genug, um die zugrunde liegende Architektur etwas genauer unter die Lupe zu nehmen und es selbst einmal mit einer eigenen Erweiterung zu versuchen.

Die Zahlen sprechen für sich. Über vier Millionen Downloads, mehr als 50 kommerzielle Produkte und über 200 Open-Source-Projekte, die alle eines gemeinsam haben: Eclipse als offene und herstellerneutrale Plattform für Softwarewerkzeuge. Die Einschätzung, dass eine integrierte Anwendungs-Entwicklungsumgebung (Integrated Development Environment, IDE) nur durch den Zusammenschluss möglichst vieler Tool-Anbieter erfolgreich sein kann, hat sich also für die Initiatoren, allen voran IBM, voll bestätigt.

Seit im November 2001 mit der Freigabe des Quellcodes die Umsetzung dieser auch für Big Blue neuen Produktstrategie begann, wächst die Community rund um das gemeinschaftlich entwickelte Projekt stetig. Maßgeblich daran beteiligt ist die Schweizer IBM-Tochter Object Technologie International (OTI), deren Technical Director, der auch als Pattern-Papst bekannte Erich Gamma, schon für die Entwicklung des Eclipse-Vorgängers Visual Age for Java technologisch verantwortlich war.

Die Neutralität wird durch die Mitgliedschaft weiterer namhafter Partner in der Eclipse Projektmanagement-Kommission (PMC) wie Borland, Hewlett-Packard, SuSE oder Red Hat gewahrt. Seit kurzem ist diesem Kreis auch SAP beigetreten. Die Walldorfer Schwergewichte sehen Eclipse als Erfolg versprechende Ergänzung der zunehmend von J2EE bestimmten Systemarchitektur ihrer Unternehmenssoftware.

Neuestes Java-SDK ist wünschenswert

In Anbetracht der stattlichen Größe von knapp 65 MByte für das Zip-Archiv der Eclipse-Plattform existieren inzwischen neben der zentralen, in Nordamerika beheimateten Bezugsquelle einige regionale Mirror Sites. Für die deutschsprachige Eclipse-Gemeinde verspricht der in der Schweiz betriebene Sunsite-Server[1] einen hohen Datendurchsatz und ein tagesaktuelles Update.

Voraussetzung für die Installation ist ein Java-SDK ab Version 1.3. Empfehlenswert ist die neueste Version 1.4, denn nur damit lässt sich das so genannte Hot Code Replacement des Java-Debuggers in Eclipse nutzen.

Reparatur zur Laufzeit

Das bisher nur den Visual-Age-Entwicklern vorbehaltene Feature ermöglicht das Austauschen von fehlerhaftem Code zur Laufzeit im Debugger, ohne das Programm erneut starten zu müssen – eine besonders beim Einsatz eines Application-Servers sehr zeitsparende Funktionalität. Für die von einigen als komfortabler und ergonomisch empfundene GTK-Version der Plattform sind mindestens die GUI-Bibliotheken ab Version 2.0.6 erforderlich, was auch schon unter Red Hat 7.3 zu Problemen mit den Paketabhängigkeiten führt und ein aufwändiges Update erfordert.

Die Motif-Version ist in diesem Punkt weit weniger anspruchsvoll. Nur die Programmbibliothek »libXm.so.2.1« in dem Hauptverzeichnis der Eclipse-Installation ist in »/etc/ld.so.conf« nachzutragen. Mit

/sbin/ldconfig

werden die Referenzen auf die dynamisch gelinkten Programmbibliotheken erneut geladen. Einem erfolgreichen Start der IDE mit

eclipse -data $HOME

steht nun nichts mehr im Wege. Der Parameter »-data« weist Eclipse an, das Arbeitsverzeichnis (Workspace) relativ vom angegebenen Pfad, in diesem Fall im Homeverzeichnis des entsprechenden Systembenutzers, anzulegen.

Abbildung 1: Quick Fix: Fehlererkennung und Korrektur während der Eingabe.

Alles ist ein Plugin

In erster Linie hat Eclipse keinen direkten Bezug zu Java oder irgendeiner anderen Programmiersprache. Vielmehr verfolgt die Plattform das Ziel, durch eine stark komponentenbasierte Architektur die flexible Integration beliebiger Funktionalitäten zu ermöglichen. Die muss nicht zwingend etwas mit Programmentwicklung zu tun haben. Die meisten der heute kostenlos oder gegen eine Lizenzgebühr erhältlichen Komponenten, auch als Plugins bezeichnet, sind jedoch Entwickler-Tools, also Compiler, Editoren, Modellierungswerkzeuge oder Debugger.

So auch die automatisch installierte Unterstützung für die Programmiersprache Java in Form der so genannten Java Development Tools (JDT), die konsequenterweise auch aus einer Sammlung von Plugins bestehen. Besinnt man sich aber auf die pure Basisfunktionalität von Eclipse als nackte Laufzeitumgebung für Plugins zurück, lassen sich auch grundverschiedene Einsatzszenarien vorstellen. Beispielsweise ein flexibel erweiterbares Grafikprogramm, in dem der Editor als Basiskomponente (natürlich auch ein Plugin) mitgeliefert wird und zusätzlich Grafikfilter und -formate als Plugins installiert werden können.

Das ist ein Konzept, das marktführende Unternehmen schon mit Erfolg umgesetzt haben. In dieser Architektur liegt der Hauptunterschied zu herkömmlichen IDEs begründet, in denen Basisfunktionalitäten immer ein fester und nicht austauschbarer Bestandteil einer monolithischen Laufzeitumgebung sind.

Funktionalität

Insgesamt präsentiert sich die Eclipse- Java-IDE dem Entwickler als eine überaus transparente Entwicklungsumgebung. Visual-Age-Umsteiger werden es beispielsweise zu schätzen wissen, dass der Code nicht mehr länger in einem proprietären Repository landet, sondern direkt im Dateisystem an beliebig konfigurierbarer Stelle liegt. Damit öffnet sich die IDE auch den Anhängern von »sed«, »grep« und anderen externen Werkzeugen, die nach wie vor eine große Hilfe sein können.

Andererseits wurden gerade die in Visual Age als komfortabel geschätzten Funktionalitäten, etwa die interne Änderungshistorie, beibehalten und gleichzeitig die Team-Entwicklung über eine enge Integration mit gängigen Versionskontrollwerkzeugen wie etwa CVS implementiert.

Besseres Refactoring in der neuen Version

Die am 27. März 2003 erschienene Release 2.1 baut eine der wesentlichen Stärken von Eclipse, die Unterstützung für strukturelle Veränderungen im Code (Refactoring), noch weiter aus. So lässt sich beispielsweise per Mausklick nachträglich ein direkter Zugriff auf lokale Variablen klassenweit zur Verwendung Bean-konformer Getter- und Setter-Methoden umbauen.

Neu ist auch die Möglichkeit, automatisch Methoden für das Delegate-Entwurfsmuster[2] zu generieren. Alle Änderungen lassen sich in einer Voransicht zuerst begutachten, bevor sie tatsächlich umgesetzt werden. Bemerkenswert ist zudem die erweiterte Quick-Fix-Funktion (siehe Abbildung 1), die nicht nur den Code schon während der Eingabe auf Fehler analysiert, sondern auch gleich dem Entwickler auf Wunsch unterschiedliche Vorschläge zu deren Korrektur unterbreitet.

Was spricht angesichts dieser Funktionalität eigentlich noch für den Wechsel zur kommerziellen Variante? Vermissen werden Entwickler grafischer Benutzeroberflächen beispielsweise einen visuellen GUI-Builder. Auch einen leistungsfähigen Editor für Java Server Pages (JSP) mit Syntax-Highlighting und automatischer Code-Vervollständigung sucht man vergebens. Ein weiterer Wermutstropfen wird die fehlende Integration mit einem der gängigen Application Server aus dem J2EE-Umfeld sein.

Abbildung 2: JSP-Debugging mit dem Tomcat-Plugin von Sysdeo.

Angedockt – Plugins für J2EE

Mit etwas Sucheifer wird man jedoch gerade zu dem letzten Punkt schnell unter den zahlreich vorhandenen Plugins fündig. Empfehlenswert für das Nachrüsten der Basisinstallation ist das von der französischen Softwareschmiede Sysdeo[3] zum kostenlosen Download angebotene Plugin für die bekannte Servlet- und JSP-Engine Tomcat. Die Installation ist wie bei allen Plugins denkbar einfach: nur das zugehörige Zip- oder Tar-Archiv im Eclipse-Unterverzeichnis »plugins« entpacken und die IDE neu starten – fertig.

Sysdeo liefert keine eigene Version von Tomcat mit, sondern setzt mit dem Plugin auf einer zwingend vorhandenen Installation auf. Das bietet den Vorteil hoher Flexibilität hinsichtlich der verwendeten Version, da das Plugin für Tomcat 3.x bis 5.x konfiguriert werden kann. Einmal installiert möchte man das komfortable Starten oder Stoppen der Engine direkt in Eclipse und die Möglichkeit des Debuggens von JSPs nicht mehr missen (siehe Abbildung 2).

Dazu ist es allerdings nötig, in der Tomcat-Konfigurationsdatei »server.xml« einen zusätzlichen Eintrag für den Kontext der Webapplikation zu konfigurieren. Das temporäre Verzeichnis für die aus den JSPs generierten Servlets muss in den für Eclipse zugänglichen Projektbereich gelenkt werden. Das Umlenken erfolgt mit:

workDir="path-to-sources/work/org/apache/jsp"

Gibt man diesen Pfad in den Projekteigenschaften als zusätzliches Quellcodeverzeichnis an, dann steht dem Zugriff auf die Servlets im Debugger nichts mehr im Wege.

Gerade komplexe und mehrschichtige J2EE-Anwendungen haben häufig eine Datenbank integriert, auf die der Entwickler immer ein Auge werfen möchte. Hier erwies sich das Quantum-DB-Plugin[4] als kostenlose und nützliche Alternative. Viele gängige Datenbanksysteme unter Linux wie MySQL, PostgreSQL oder DB 2 lassen sich einfach mit ihm in die IDE einbinden. Es können Abfragen unter Fortführung einer Historie gestartet, Metadaten zu Tabellen abgefragt und die gesamte Datenbank als Baumstruktur betrachtet werden.

Plugins einfach selbst geschrieben

Wen jetzt der Ehrgeiz packt, selbst die lang ersehnte IDE-Erweiterung zu implementieren, der erhält von Eclipse umfangreiche Unterstützung zur Erstellung eigener Plugins. Neben den JDTs wird eine komfortable Plugin-Entwicklungsumgebung (Plug-In Development Environment, PDE) installiert, die über »File | New | Project | Plug-In Development« mit einem Wizard den Einstieg in die Komponentenarchitektur von Eclipse mit fertigen Vorlagen erleichtert. Eine gute Einführung bietet dabei ebenfalls der PDE Guide, der über die Online-Hilfe zu finden ist.

Zentraler Bestandteil jedes Plugins ist neben den eigentlichen Java-Klassen die so genannte Manifest-Datei »plugin .xml«. Sie gibt Auskunft über die allgemeine Konfiguration dieser kleinsten ausführbaren Einheiten und beschreibt deren Integration in die Plattform. Die kann an unterschiedlichen, im Eclipse-Framework aber klar definierten Stellen erfolgen. Beispiele für diese so genannten Extension Points sind neue Editoren (»org.eclipse.ui.editors«), Einträge in der Menüleiste (»org.eclipse.ui.actionSets«) oder eine eigene Seite im Konfigurationsdialog (Preference) der Workbench (»org.eclipse.ui.preferencePage«).

Im Folgenden wird an einem überschaubaren Beispiel die XML-Funktionalität der Plattform durch ein Plugin erweitert. Der Anwender soll auf Grundlage eines im Projekt eingebundenen XML-Dokuments dessen Elemente und deren Häufigkeit auf besonders einfache Weise analysieren können.

Dazu bietet es sich an, für Dateien mit der Endung ».xml« einen zusätzlichen Eintrag »XML Processing« im Kontextmenü mit einem Untereintrag »Count Elements« vorzunehmen, der die beschriebene Funktion ausführt. Realisiert wird das Vorhaben über ein Plugin, das am Extension Point »org.eclipse.ui .popupMenus« für Kontext- oder Popup-Menüs andockt (Abbildung 3).

Die zugehörige Manifest-Datei in Listing 1 ist weitgehend selbsterklärend: Neben übergeordneten Angaben wie einer eindeutigen Referenz-ID, dem Jar-Archiv mit den Klassen (»<runtime>«) und Abhängigkeiten (»<requires>«) zu anderen Plugins, die ebenfalls über ihre ID referenziert werden, können ein oder mehrere Extension Points (»<extension>«) definiert werden. Jeder dieser Anknüpfungspunkte kennt zusätzliche Attribute, die eine genaue Konfiguration des Plugins ermöglichen.

Im vorliegenden Fall wird beispielsweise der Eintrag im Kontextmenü nur dann angezeigt, wenn sich die Maus dabei über einer Datei-Ressource (»objectClass =”org.eclipse.core.resources.IFile”«) mit der Endung ».xml« befindet (»nameFilter=”*.xml”«). Die bei der Auswahl aufzurufende Klasse wird im XML-Tag »<action>« mit »class=”net.raepple .plugin.popup.actions.CountElements”« angegeben. Aus Gründen der Performance lädt Eclipse den Plugin-Code normalerweise niemals sofort beim Systemstart, sondern erst zum Zeitpunkt des Aufrufs.

Die gesamte Konfiguration in »plugin .xml« kann mit dem Plugin Manifest Editor komfortabel editiert werden, der zu einem der wesentlichen Bestandteile des PDE zählt. Soll die Entwicklung von Plugins und zugehörigen Klassen von anderen Projekten getrennt sein, bietet sich wiederholt die Verwendung des Parameters »-data <Plug-In-Workspace>« beim Start von Eclipse an.

Einstiegspunkt für die Funktionalität des Plugins ist die bei der Auswahl des Menüpunkts im Attribut »<action>« angegebene Klasse »CountElements« (»CountElements.java« ist aus Platzgründen nur online verfügbar[7]). Sie wird durch den Wizard automatisch erzeugt und implementiert das Java-Interface »IObjectActionDelegate«.

SDK-Kenntnisse gefragt

Spätestens jetzt lohnt sich für den Entwickler ein genauerer Blick auf die Eclipse-eigene GUI-Bibliothek (Standard Widget Toolkit, SWT), die in[5] bereits ausführlich vorgestellt wurde. So viel an dieser Stelle: Durch das Interface sind die Methoden »run()« und »selectionChanged()« zu implementieren, die bei einem Zugriff auf das ausgewählte Objekt (die XML-Datei) aufgerufen werden und eine Initialisierung der weiteren Schritte ermöglichen.

Und die gestalten sich konkret so, dass in Folge der Auswahl ein Wizard-ähnlicher Dialog (siehe Abbildung 4) geöffnet wird, der den Benutzer zur Eingabe eines Elementnamens auffordert. Die zugehörige Klasse »XMLElementCountWizard« (aus Platzgründen nur online[7]) leitet sich von der SWT-Komponente »Wizard« ab und überschreibt deren Methoden »addPages()« und »performFinish()«. Die erste fügt zunächst eine einzelne Dialogseite vom Typ »XMLElementCountPage« hinzu, die von der abstrakten Oberklasse »WizardPage« erbt. Das Erzeugen benutzerspezifischer GUI-Elemente erfolgt durch Überschreiben der vom Wizard aufgerufenen Methode »createControl()«.

Nach Bestätigung der Eingabe wird »performFinish()« ausgeführt. Da nun alle notwendigen Informationen – XML-Datei und Elementname – vorliegen, kann mittels JAXP und des DOM-API der gewünschte Wert recht elegant und ohne großen Aufwand ermittelt werden. Das Ergebnis erhält der Entwickler in Form einer Benachrichtigung (Abbildung 5). Neben diesen selbst erstellten Klassen wird bei der Erzeugung des Plugins automatisch eine Hauptklasse generiert, die bereits komplett fertige Methoden zur Abfrage von Informationen der Laufzeitumgebung (Workbench und Workspace) besitzt.

Abbildung 3: Start des Plugins über das Kontextmenü.

Lokalisierung mit Ressourcen-Bündel

Zudem verwaltet sie bei mehrsprachigen Erweiterungskomponenten ein Java-typisches Ressourcen-Bundle, über das die Inhalte aus Property-Dateien mit den sprachspezifischen Texten ermittelbar sind. Texte in direktem Zusammenhang mit der Plugin-Konfiguration wie beispielsweise die Menü-Einträge können einfach in »plugin.xml« mit einem »%« am Anfang versehen werden.

Dann wird automatisch gemäß den Java-Suchregeln für Sprach-Ressourcen eine entsprechende Übersetzung ermittelt. Dazu muss zumindest die Datei »plugin .properties« im Hauptverzeichnis des Plugins vorhanden sein. Sie hat im konkreten Beispiel folgenden Inhalt:

menu_entry = XML Processing
action_count_elements = Count Elements

Zusätzliche Sprachen stehen durch Dateien mit entsprechender Landeskennung und Übersetzung (etwa als »plugin _de.properties«) bereit.

Auf der Suche nach Fehlern unterscheidet sich das Vorgehen bei der Plugin-Entwicklung etwas von dem in klassischen Eclipse-Projekten. Eingeleitet wird das Debugging durch den Start einer zweiten Workbench (»Run | Debug as | Run-time Workbench«), die als Laufzeitumgebung für den Testkandidaten dient. Das Setzen von Breakpoints und die Steuerung des Programmablaufs geschieht jedoch nach wie vor in der ersten Workbench.

Sind alle Fehler beseitigt, sollte dem Rest der Welt das neue Plugin nicht länger vorenthalten bleiben. Dazu könnte man es einfach als Zip- oder Tar-Archiv zusammenpacken und es zum Download ins Web stellen. Etwas eleganter ist der Ansatz über den Update-Manager in Eclipse, der bei der Installation neuer Erweiterungen Abhängigkeiten und Versionsstände zu anderen Komponenten, Inkompatibilität zum Betriebssystem und vieles mehr prüfen kann.

Für den Plugin-Benutzer reduziert sich der Installationsaufwand auf die Eingabe einer URL im Update-Manager (»Window | Open Perspective | Install/Update«), von der er den Code für die Erweiterungen bezieht. Als Anbieter von Plugins kann man sich über »New Project | Plug-In Development | Update Site Project« eine solche Update-Site einrichten.

Abbildung 4: Wizard zu dem XML-Element Count.

Abbildung 5: Der Entwickler wird über das Ergebnis benachrichtigt.

Fazit

Open Source funktioniert. Das wird mehr als deutlich an so erfolgreichen Projekten wie Eclipse, die es verstehen, die Möglichkeiten kommerzieller Anbieter mit den Interessen und Zielen der offenen Entwicklergemeinde zu vereinen. Unterstützt das technische Konzept zudem noch diesen gemeinschaftlichen Software-Erstellungsprozess mit einer innovativen und durchdachten Komponentenarchitektur, entsteht im Ergebnis ein für den professionellen Einsatz bestens geeignetes Produkt.

In der neuen Version 2.1 ist Eclipse zu einer sehr stabilen und funktional umfangreichen Plattform gereift, die es ermöglicht, schnell und effektiv eigene Erweiterungen zu erstellen. Wünschenswert für die Zukunft ist eine etwas stärker von IBM entkoppelte Entwicklung der Plattform. Erste Ansätze dazu sind erkennbar, vor allem in Java-fremden Bereichen wie C++ oder C#. (uwo)