Eclipse Plug-ins. Michael Perscheid Seminar System Modeling 2005 Hasso-Plattner-Institute for Software Systems Engineering

Transkript

1 Eclipse Plug-ins Michael Perscheid Seminar System Modeling 2005 Hasso-Plattner-Institute for Software Systems Engineering Übersicht Dieses Dokument beschäftigt sich mit den Konzepten und Technologien von Eclipse Plug-ins. Es wird gezeigt, wie man Eclipse erweitert und wie sich Plug-ins strukturell aufbauen. Anschließend wird auf die einzelnen Komponenten und Technologien eingegangen, um deren Verbindung zum Gesamtaufbau darzulegen. Am Ende wird anhand des JDT (Java Development Tool) die Einbettung von Plug-ins in Eclipse dargestellt. Schlüsselwörter: Eclipse Plug-in Architektur, Manifest, Extension Point, OSGi Framework, Java Development Tool 1. Einleitung Eclipse ist eine universelle Plattform, auf der alle möglichen Programme laufen können. Um dies zu realisieren, benötigt man Plug-ins und weitere wichtige Konzepte. Eclipse bietet grundsätzlich 3 Möglichkeiten es zu erweitern, daher sind die normalen Bibliotheken und Dokumentationen nur der Vollständigkeit halber genannt. Die wichtigste Möglichkeit ist das Konzept, dass die eigentliche Plattform mittels Plug-ins erweitert wird. Dabei gilt, dass Eclipse nahezu vollständig aus diesen aufgebaut ist. Die kleinste Einheit in Eclipse, welche separat ausgeführt werden kann, nennt man Plug-in. Es ist ein strukturiertes Bündel aus essourcen, welches die Möglichkeit bietet sich über festgelegte Schnittstellen in Eclipse einzuklinken. Auch gibt es die Möglichkeit, selbst solche Stellen zu schaffen und somit aus vielen kleinen Komponenten ein großes Ganzes zu schaffen. Dabei ist es wichtig zu beachten, dass die hierarchische Anordnung der Plug-ins und ihrer Schnittstellen nicht verletzt wird (keine Bildung von zyklischen Abhängigkeiten). Ebenso kann jedes Plug-in in Eclipse nur einmal gestartet werden, deshalb werden viele mittels des Singleton Pattern realisiert. Lazy loading bietet eine Möglichkeit um Grenzen bei der Menge an Plug-ins zu umgehen. Hierbei wird jeweils - erst beim wirklichen Bedarf - die eigentliche Komponente geladen. Dies wird einerseits mit der Bekanntmachung der Plug-ins, mittels ihres Manifests und andererseits mit dem OSGi-Framework realisiert. An dieser Stelle sei auf The Eclipse Platform (siehe [1]) verwiesen, welches zum besseren Verständnis von Eclipse und dessen Architektur beiträgt. 2. Problem Das Plug-in-Konzept ist ein mächtiges Werkzeug, um Eclipse zu nutzen und zu erweitern. Doch besteht deren Dokumentation meist nur aus Tutorials und vielen verstreuten Informationen. Diese Ausarbeitung soll helfen, die wichtigsten Informationen zu Plug-ins zusammenzustellen und dabei ihren Zusammenhang in das Gesamtkonzept zu verdeutlichen. Des Weiteren soll auch das Verständnis für eine abstrakte Vorstellung, für die Handhabung, sowie der Technologie von Plug-ins in Eclipse gestärkt werden. Im Inhalt wird sich jedoch keine Anleitung für die Entwicklung eines Plug-ins finden 1. Jedoch sei mir an einigen Stellen erlaubt, auf kleinere Tipps für den Umgang mit Plug-ins und der PDE 2 einzugehen. 1 Dieser Bedarf sollte von anderen Quellen mehr als gedeckt sein. (siehe [6]) 2 Plug-in Developer Environment

2 resources Feature icon library owns Manifest - name - id - version documentation consists of uses references to consists of Plug-In Fragment Extension Point Dependency Point Java Code 1 contains 0,1 has parent provides 3. Plug-in Architektur 3.1. Struktur p,e provides, p,m owns e,m references to p,e uses, p,m owns e,m references to p - Plug-in / Fragment e - Extension Point / Dependency Point m - Manifest Das Entity-elationship-Diagramm in Abbildung 1 verdeutlicht den grundlegenden Aufbau von Plug-ins. Dabei lässt sich dort leicht erkennen, dass es 3 Teilarten von Komponenten gibt. Das Feature besteht aus einem oder mehreren Plug-ins. Es ist damit die kleinste, herunterladbare und installierbare Einheit in Eclipse. Die Unterscheidung wird getroffen um, großen Projekten eine Abstraktion von Plug-ins zu geben und somit das Installieren von Komponenten zu erleichtern. Features spielen hier nur eine kleine olle und werden außerhalb von Eclipse gerne mit dem Begriff Plug-in gleichgesetzt. Das eigentliche Plug-in ist die Hauptkomponente in der Architektur. Es ist eine Kapselung von Verhalten und/oder Daten, welches dazu, dient mittels anderer Plug-ins ein lauffähiges Programm zu erschaffen. Sie besitzen jeweils genau ein Manifest, welches die Abbildung 1 Plug-in Struktur Grobstruktur des jeweiligen Plug-ins beschreibt. Zusätzlich können noch optional Java Code oder eine bzw. mehrere essourcen genutzt werden. Die letzte Komponente sind die so genannten Fragmente. Sie gelten als optionale Teile eines Plug-ins. Damit ist es möglich sie unabhängig vom Host-Plug-in zu installieren oder zu verändern. Sie besitzen daher auch genau die gleiche Struktur wie Plug-ins (d.h. ein Manifest, optional essourcen, Java Code). Im Gegensatz zu Plug-ins sind Fragmente nicht allein lauffähig, denn sie benötigen immer ein Host-Plug-in von dem sie auch die Abhängigkeiten erben und somit benutzen können. Es gilt, dass Fragmente von der untime logisch aber nicht physisch dem Host-Plug-In zugeordnet werden, d.h. auch das Plug-in selber sieht das Fragment als optional an und ist auch ohne ihn lauffähig. Aus diesem Grund werden sie gerne für Spracherweiterungen genutzt. Ein verbreiterter Missbrauch von Fragmenten findet beim Patchen von Plug-ins statt. Dabei nutzt man den Ladezyklus der untime aus und trägt das Fragment vor dem eigentlichen Laden des Plug-ins ein. Diese Praxis ist zwar sehr umstritten, allerdings bietet Eclipse im Moment

3 keine Alternative dafür Manifest Das Manifest beschreibt den groben Aufbau eines Plug-ins oder Fragments. Darin enthalten sind wenigstens der Name, die Version und eine eindeutige ID mit der die untime das Plug-in identifizieren kann. Ebenso findet man dort sämtliche Abhängigkeiten 3 die ein Plug-in benötigt oder benutzt. An dieser Stelle sei kurz auf die Formel unterhalb des Diagramms eingegangen. Sie bedeutet, dass es für jede Abhängigkeit im Plugin, sei es nun Bereitstellung oder Benutzung, eine eindeutige eferenz im Manifest von ihm geben muss. Sollte eine Abhängigkeit benutzt werden, welche nicht hier aufgelistet ist, so kann man sie auch nicht verwenden. Das Manifest basiert auf der XML- Technologie, wobei dies für die Entwickler zweitrangig ist, da Eclipse mit dem PDE einen sehr guten Editor bereitstellt. Dieser sollte auch unbedingt benutzt werden, da Fehler im Manifest die Ladbarkeit des eigenen und anderer Plug-ins gefährden. Zu beachten ist, dass die Manifestdatei plugin.xml bzw. fragment.xml heißen muss. Beispiel <?xml version="1.0" encoding="utf-8"?> <plugin id="de.myexample.eclipse" name="helloworld Plug-in" version="1.0.0" provider-name= Max Muster" class="de.myexample.eclipse.helloworldplugin"> An diesem Beispiel erkennt man, dass auch zusätzliche Einträge erlaubt sind und auch oft genutzt werden. Vor allem Dokumentation zu dem Plug-in wird meist erweiternd bereitgestellt. Sollte die Komponente Javacode bereitstellen, so muss natürlich auch eine Startklasse angegeben werden, welche wiederum eine Subklasse von org.eclipse.core.runtime.plugin sein muss, damit Eclipse den Einstiegspunkt finden kann. Der Sinn des Manifests liegt nun in der lazy loading Möglichkeit von Eclipse Lazy Loading Mit diesem Konzept ist es möglich, beliebig viele Plug-ins zu installieren, ohne einen Verlust von Performance zu haben. 3 Abhängigkeiten bestehen hier aus Dependencies und Extension Points Beim Start von Eclipse wird das Plug-in Verzeichnis (hier befinden sich alle installierten Plug-ins) gelesen, dabei werden alle Manifeste in die egistry geladen. Die Platzhalter geben nun Auskunft über Abhängigkeiten und stellen sozusagen einen Schatten (nur Plug-in Manifeste sind geladen aber der Code selbst noch nicht) aller möglichen Plug-ins dar. Nun gilt es, die notwendigen Core-Plug-ins zu laden. Diese stellen Kernfunktionalitäten bereit und müssen somit von Anfang an verfügbar sein. Alle anderen Non-Core-Plug-ins werden erst nach Bedarf geladen, d.h. wenn ihre Funktion benötigt wird. Dabei geht Eclipse in die egistry, schaut sich dort das Manifest des jeweiligen Plugins an und lädt gegebenenfalls untime- Abhängigkeiten. Als letzten Schritt startet die untime nun das Plug-in und lädt, falls notwendig, weitere Abhängigkeiten, wenn sie im Code auftreten Dependencies Mit Dependencies werden Verbindungen zu Funktionen anderer Plug-ins oder Funktionsbibliotheken beschrieben, welche ein Plug-in benötigt. Auch gibt es die Möglichkeit, eigene Klassen etc. nach außen zu öffnen. Bei den Dependencies unterscheidet Eclipse zwei Arten, welche sich nur im Lademechanismus unterscheiden. Normale Dependencies werden erst beim eigentlichen Bedarf im Sourcecode geladen. Für Entwickler heißt dies, dass man sie erst möglichst spät einbinden sollte. untime Dependencies unterscheiden sich im Gegensatz dazu in dem Punkt, dass sie immer bevor das Plug-in gestartet wird, geladen sein müssen. Dies sind also meist die Standardbibliotheken oder Core-Plug-ins. Da Dependencies auch im Manifest stehen müssen, unterscheidet man die Angebotsseite, welche ebenso bekannt gemacht werden muss, bevor das Plug-in geladen wird und die Nachfrageseite, welche sich in Normal und untime unterscheidet. Auch hier gilt wieder: Wenn Fehler im Manifest auftreten, kann man zwar sein Plug-in kompilieren aber nicht ausführen. Beispiel <runtime> <library name="eclipse.jar"> <export name="com.myexample.*"> </library> </runtime>

4 <requires> <import plugin="org.eclipse.core.*"/> </requires> Das Beispiel zeigt die Angabe mehrerer Dependency Points, wobei sowohl die Benutzung von runtime (library) und normalen Dependencies (requires, import) beschrieben wird, als auch die Bereitstellung des Plug-ins nach außen (export) Extension Points Dieses Kernkonzept bietet die Möglichkeit, sich bei anderen Plug-ins einzuklinken und sie somit zu erweitern. Dies ist also genau das Gegenteil der Dependencies, bei denen man auf bereitgestellte Funktionen von anderen Komponenten zurückgreift, um sie selbst zu nutzen. Extension Points bilden daher Schnittstellen, welche einen eindeutigen Namen besitzen und meist eine Kombination aus XML- Einträgen und einem Java-Interface sind. Ein Plug-in, welches solch einen Punkt erweitern will, muss also alle Spezifikationen die dieser bereitstellt ausfüllen, d.h. XML-Einträge spezifizieren und das Java-Interface implementieren. Dabei kann das Host-Plug-in selbst eine Default-Implementierung bereitstellen. In Abbildung 2 ist nun ein mögliches Klassendiagramm, welches diesen Zusammenhang ausdrückt dargestellt. Abbildung 2 UML Extension Point All diese Einträge müssen wiederum im Manifest stehen, damit Eclipse jederzeit weiß, wer welche Extension Points anbietet und wer welche erweitert. Intern wird dies über so genannte Querverweise (Crosslinks) realisiert. Da sie nun sehr groß und komplex werden können, lagert das PDE sie aus dem Manifest in eigene Schemata. Dadurch erhöht sich die Übersichtlichkeit und Entwicklern wird es leichter gemacht, sich in den Extension Points zurecht zu finden. In Eclipse stehen nun genau 3 Arten von Extension Points zur Verfügung: Bei der ersten Form stellt das Host-Plug-in ein Interface bereit, welches implementiert werden muss. Diese Implementierung wird dann vom Host-Plug-in gestartet und abgearbeitet (siehe auch ). Zum Beispiel Anwendungen allgemein; welche mittels Eclipse ausgeführt werden und somit nur IPlatformunnable implementieren müssen. Die zweite Art basiert nur auf XML-Einträgen, welche zur Erweiterung angegeben werden müssen. Das eigentlich Verhalten darauf ist im Host-Plug-in gekapselt und kann nur über die Spezifikationen verändert werden. Plug-ins, welche nur solche Extension Points nutzen, benötigen meist keinen eigenen Java Code, da sie alles über die XML-Einträge erklären. Beispiele hierfür sind Sprachpakete oder der Extension Point Ignore. Bei diesem jedoch, gibt man nur an, welche Dateiendungen das System Ignorieren soll. Die dritte und letzte Form ist eine Mischung aus Beidem. Dort realisiert ein Teil das Verhalten des Host-Plug-ins (XML-Einträge) und der andere die Implementierung des Interfaces. Bekannte Beispiele hierfür sind die SWT/JFace 4 Extension Points, dabei gibt man im Manifest an, wie Buttons, Menüs etc. auszusehen haben aber das eigentliche Verhalten wird dann über die Interfaceimplementierungen definiert. Da Eclipse, wie bereits erwähnt, nahezu nur aus Plug-ins aufgebaut ist, benötigt jede Erweiterung auch einen Extension Point an dem es sich an der entsprechenden Stelle in Eclipse einklinken kann. Die Tags im Manifest sehen auf Angebots- und Nachfrageseite sehr ähnlich aus. Eclipse kann dies nun aber über die Pfade entscheiden: So heißt ein relativer Pfad, das Plug-in bietet ein Extension Point an, wobei ein absoluter Pfad bedeutet, man möchte den Extension Point von einem anderen Plug-in nutzen. Für Entwickler sei jedoch erwähnt, dass diese Beschreibung sehr allgemein gehalten wurde und für die Entwicklung von Plug-ins ein ausführliches Studium der entsprechenden Extension Points nötig ist. 4 Eclipse GUI (siehe [1])

5 Host-Plug-in Implementation Die Implementierung von Host-Plug-ins muss einen Algorithmus bieten, mit dem man alle Erweiterungen an einem Extension Point abfassen kann, ohne jedes Mal neu zu kompilieren. Dieser ist in Abbildung 3 dargestellt. Um ihn zu verstehen ist ein Systemverständnis von Eclipse sehr wichtig, da beide sehr eng zusammenarbeiten. Connect to Platform egistry egistry: Choose Extension Point ead all extensions in a list no further extensions ead all elements from extension in a list No further elements Extension Point Handle Element Abbildung 3 Host-Plug-in Algorithmus Example egistry egistry egistry Element Element Extension Mit Hilfe des Beispiels soll das Zusammenwirken verständlicher werden. Eclipse befindet sich bereits in der Laufzeit, nun erfolgt vom Benutzer der Anstoß ein neues Plug-in zu laden. Daraufhin durchsucht die untime die egistry nach dem Manifest des zu ladenden Plug-ins. Stellt es an dieser Stelle eine Erweiterung zu einem bestehenden Extension Point fest, so wird der obige Algorithmus abgehandelt. Das Host-Plug-in verbindet sich anschließend ebenfalls mit der egistry (indirekt über die untime) und wählt den zu suchenden Extension Point aus. Daraufhin werden alle Erweiterungen, die an ihm anliegen, separat in eine Liste geladen, welche nun abgearbeitet wird. Aus jeder Erweiterung werden alle Elemente (XML- Einträge, Java Interface) herausgeholt und mit ihnen versucht umzugehen. Dabei ist bei den XML-Einträgen das Verhalten im Host-Plug-in beschrieben und bei den Java Interfaces wird versucht, mittels Java eflection, eine ausführbare Klasse zu erschaffen und sie auszuführen. Somit wird nun die komplette Erweiterung im Host- Plug-in abgehandelt. An dieser Stelle sei aus didaktischen Gründen noch kurz die Steckdosennotation erwähnt. In vielen Quellen[2],[5],[6] wird diese Notation verwendet, um das Konzept von Extension zu erläutern. Angebotene Extension Points werden dabei als Steckdosenleisten dargestellt in denen sich viele beliebige Plug-ins (Nachfrager) einklinken können und somit eine Erweiterung darstellen. Diese können selbst auch wieder neue Steckdosen anbieten usw Installation von Plug-ins Die einfachste Art Plug-ins zu installieren: Man kopiert sie einfach in den Ordner /eclipse/plugins/, welcher bei jedem Start von Eclipse komplett durchsucht wird und alle gefunden Manifeste lädt. Eine weitere Möglichkeit ist es, den Software Update Manager 5 zu nutzen, welcher unter Angabe einer UL ein gesamtes Feature herunterlädt und installiert. Zur Verwaltung von Plug-ins bietet Eclipse ebenso einen lokalen Browser 6 mit dem man sie aktivieren/deaktivieren kann. Für Entwickler seien hier noch kleine Tipps erwähnt, welche unter umständen hilfreich sein könnten. /workspace/.metadata/.log bietet reichhaltige Informationen über den Status von Eclipse. Eine Liste aller gefundenen Plug-ins findet man unter Help -> about eclipse platform -> Plug-in details und detaillierte Informationen zum Ladestatus einzelner Plug-ins erhält man durch das Anlegen eines neuen Plugin-Projekt mit dem PDE. In der neu geladenen Perspektive ist im Log-View einiges an Informationen enthalten. 4. OSGi 7 Framework Das OSGi-Framework[3] ist ein offener Standard für die Verwaltung von dynamischen Komponenten und eingebetteten Systemen. Da Eclipse genau diese Ansprüche stellt, bietet sich das Framework sehr gut als Implementierung an. Dazu ist allerdings noch zu sagen, dass die Umsetzung etwas vom Standard abweicht. Das OSGi-Framework sieht vor, dass Softwarekomponenten dynamisch installiert, 5 Help -> Software Updates -> Find and Install 6 Help -> Software Updates -> Manage Configuration 7 Open Services Gateway Initiative

6 gelöscht und geändert werden können. Ebenso soll es die Möglichkeit des selektiven Exports von Teilen der Komponenten geben. Es soll komplett vom Benutzer verdeckt sein, sodass er nach wie vor nur mit der Plattform untime arbeitet. Auch bezeichnet nun der Standard Komponenten als Bundles, welche ihren eigenen Java Class Loader und ein Protokoll zur Verwaltung des Zustandes (installiert, entfernt, gestoppt etc.) besitzen. Das Framework selber unterteilt sich in 4+1 Schichten. L0: Execution Environment, ist im Allgemeinen die JVM oder eine andere ausführbare Umgebung. L1: Modules, bezeichnet alle essourcen, Klassen und Softwarekomponenten, sowie die OSGi spezifischen Erweiterungen. L2: Life Cycle Management, verwaltet das dynamische Leben der Bundles. L3: Service egistry, verwaltet nun die Bundles intern (z.b. ihren Zustand). Die letzte Schicht ist das Security System, welches mit allen anderen Schichten verknüpft ist und somit für die Sicherheit sorgt. So geht die Kommunikation zwischen den Komponenten oder Anfragen nach essourcen über sie. Bildet man dieses System auf Eclipse ab, so sieht man, dass bestimmte Funktionalitäten nur teilweise übernommen wurden. Abbildung 4 zeigt eine Verfeinerung der untime (Original aus [1]) und die Implementierung der Schichten. Man kann an dieser Abbildung leicht alle Schichten wieder finden. Die JVM spiegelt L0 wider, wobei alle Plug-ins auf sie zugreifen können. Die L1 Modul Schicht findet sich im Plug-in directory wieder, wo sich alle essourcen befinden. Platform esources Plug-In Workbench Plug-In Activated Plug-Ins Plug-In egistry Eclipse IDE Plug-In Directory (Modules) Java Execution Environment JVM Lifecycle Manager Service registry manager Abbildung 4 Eclipse untime OSGi Workbench Security Service OSGi Framework Platform untime harddisk L2 ist der Steuerakteur für die dynamischen Plug-ins. Hier treten auch die ersten Unterschiede auf. Seit Version 3.0 ist das dynamische installieren von Plug-ins möglich. Dafür müssen die entsprechenden Extension Points genutzt werden, um die Abwärtskompatibilität zu sichern. In diesen sind bestimmte Methoden deklariert (start/stop), mit denen die essourcen dynamisch angefordert werden. Sind diese Methoden nicht implementiert, so ist das Installieren während der Laufzeit auch nicht möglich. Die Deinstallation von Plug-ins soll erst ab Version 3.1. unterstützt werden, da sich hier jedoch einige Probleme in Bezug auf die Laufzeit- Abhängigkeiten ergeben, kann die Entwicklung dieser Extension Points noch etwas andauern. Der Lifecycle Manager realisiert also im Groben die leazy loading Politik von Eclipse. L3 befindet sich im Service egistry Manager, welcher das Laden der Manifeste und den Zugriff auf die egistry steuert. Hier werden die Konzepte für das Manifest, Extension Points und Dependencies realisiert. Die Erweiterung der Zustände für Bundles wird ebenfalls nur teilweise umgesetzt, da nicht alle Zustände benötigt werden. Der Security Service bleibt wie im Standard erhalten und steuert die Kommunikation zwischen allen Schichten und verwaltet die echte für essourcen. Man sieht, dass Eclipse das OSGi-Framework schon recht gut implementiert und die fehlenden Punkte unter Umständen in folgenden Versionen realisiert werden.

7 GUI Packages view Type hierarchy view Java editor Java outline un Preference Page Action Java Perspective JDT UI Java Model Java Builder Source files Source files Binary class files Java Problems Marker Dependency Graph Java Element Tree classpath Java Project Nature Workspace JDT Core 5. Java Development Tool Viele Menschen assoziieren Eclipse meist mit einer Java Entwicklungsumgebung, dass dem nicht so ist, sollte aus [1] und dieser Ausarbeitung ersichtlich geworden sein. Trotzdem sei an dieser Stelle kurz auf die Leistungsfähigkeit der JDT eingegangen und danach auf die eigentliche Einbettung in das Eclipse Framework. In Abbildung 5 erkennt man den grundlegenden Aufbau aus der Sicht eines Anwenders. Man greift mittels einer grafischen Oberfläche (die GUI von Eclipse) auf die entsprechenden Teile, wie die Package View oder verschiedene Editoren zu. Neben Views und Editoren gibt es auch Buttons etc. mit denen man direkte Funktionen aufrufen kann, so z.b. un. Der Benutzer selbst hat somit nur Zugriff über die grafische Benutzerschnittstelle auf das JDT UI. Alles, was im Hintergrund abläuft, behandelt die JDT Core. Dort finden sich Elemente wie das Java Model und der Java Builder, welcher den Compiler und Debugger beinhaltet. Es wird somit eine komplette Java Entwicklungsumgebung in das Eclipse SDK eingebettet. JDT bietet somit Standardmerkmale, wie z.b.: Java Projects, Editoren, Suchmöglichkeiten, Compiler und Debugger. Abbildung 5 JDT - Aufbau Die Plug-in Developer Environment greift ebenfalls auf dessen Teile zurück und nutzt sie um z.b. Plug-ins zu kompilieren Implementation ealisiert wird das Ganze nun vornehmlich über das Konzept der Extension Points (Abbildung 6 zeigt eine Aufzählung der wichtigsten Erweiterungen). Eclipse stellt auf der linken Seite Punkte für Editoren, Views, Perspektiven usw. bereit. Diese werden dann durch konkrete Plugins erweitert und implementiert. Man kann hier auch eine eindeutige Trennung zwischen Workbench und Workspace erkennen. Dies ist darin begründet, dass die grafische Benutzerschnittstelle vom Laufzeitkern abgekapselt wurde, um unabhängig davon verschiedene Möglichkeiten zu bieten. Die Trennung wurde ebenfalls vom JDT übernommen und so findet man sie im JDT UI und JDT Core wieder. Das erlaubt z.b. die Kompilation von Java Projekten mittels der Core über die Konsole JDT Core Der Kern baut sich aus folgenden drei Dingen zusammen: Java Project Nature markiert Projekte als Java spezifisch. D.h. es wird z.b. ein classpath file

8 eingeführt und der Aufbau von Klassennamen definiert. Der Java Builder bildet im Groben den Compiler und den Debugger, mit denen die Java Projects kompiliert werden können. Fehler werden über das Java Problem definiert und beim Auftreten in die Dateien/Editoren geschrieben. Eine Besonderheit bildet der Dependency Graph (siehe Abbildung 5). Mittels diesem, ist es möglich eine sehr effiziente Kompilierung auszuführen. Der Builder merkt sich, welche Dateien bereits verändert sind, welche kompiliert wurden und auf welche momentan zugegriffen wird. Somit wird bei einem un nie alles neu kompiliert - es sei dem, es ist gewünscht. Ebenso bietet es die Möglichkeit in Leerlaufphasen schon Teile vorzukompilieren, daraus folgt, dass auch ein teilweise fehlerhafter Code benutzt werden kann und große Projekte schneller lauffähig sind, da nur die veränderten Teile übersetzt werden müssen JDT UI Das UserInterface bildet die Schnittstelle zum Benutzer und bietet ihm eine Perspektive mit Action Sets (z.b. Buttons), Editoren und Views. Mit diesen kann er seine Java Projekte zusammenbauen und editieren. Um auf den essourcen zu arbeiten, bietet das JDT das Java Model Java Model Das Modell bildet eine API zur Navigation auf dem Workspace, dabei werden alle essourcen durch Objekte ersetzt, um nicht direkt auf ihnen zu arbeiten. Dazu puffert es oft gebrauchte Elemente in dem Java Element Tree und stellt somit eine sichere Schnittstelle zur Verfügung. Alle Akteure aus dem JDT UI müssen über das Model zugreifen, damit Konflikte ausgeschlossen werden. Nur der Builder hat noch direkten Zugriff auf den Speicher um seine Aktivitäten auszuführen. Workbench Elements Perspectives Views Editors Wizards JDT UI Elements Perspectives Java Perspective Views Packages View Editors Java Editor Wizards For New Java Project Type Hierarchy Perspective Type Hierarchy View Scrapbook Editor New Java Package New Scrapbook Page un and Debug Nach der Kompilation durch den Builder startet das JDT eine separate JVM, um das Programm laufen zu lassen. Damit wird sichergestellt, dass ein Fehler Eclipse nicht beeinträchtigt. Außerdem ist es somit möglich in der Debug Perspektive alle laufenden und terminierten Prozesse anzuzeigen und aus ihr heraus zu verändern. Damit wird dem Entwickler eine gute Möglichkeit geboten auf seine Programme zur Laufzeit Einfluss zu nehmen. Action Sets Property Pages Preference Pages Workspace Elements Project Natures Builders Marker Types Java Action Set Property Pages For Java Build Path Java Preference Pages Classpath Variables JDT Core Elements Java Project Nature Java Builder Java Problem Jar Source Attachments Code Formatter Java Editor Abbildung 6 Eclipse/JDT Extension Points 6. Schluss Mit dem Plug-in Mechanismus von Eclipse ist es möglich viel Funktionalität ohne einen Verlust von Performance zu realisieren. Des weiteren sind weit reichende Möglichkeiten zur Erweiterung geschaffen worden. All diese Konzepte und Technologien lassen Eclipse zu einem Musterbeispiel in vielerlei Hinsicht werden. Auch in Bezug auf die Einsatzmöglichkeiten sind Eclipse keine Grenzen gesetzt. Im Laufe der Zeit hat es sich wirklich zu einer universellen Plattform entwickelt und stellt durch seine Plattformunabhängigkeit im Zusammenspiel mit Java eine optimale Lösung für viele Probleme dar. Man kann also gespannt sein, was an Plug-ins für Eclipse noch auf den Markt kommt. Ich hoffe ich konnte mit meiner Ausarbeitung

9 einen Teil dazu beitragen, die Komplexität von Plug-ins und deren Einbettung in die Konzepte und Technologien von Eclipse zu vereinfachen, sodass es anderen Entwicklern eine Hilfe sein wird. eferenzen [1] M.Kunze, The Eclipse Platform, [2] Eclipse Foundation [3] Open Services Gateway Initiative [4] Article of Javaspektrum 2/2005 (OSGi Framework) e_js_02_05.pdf [5] J. Arthorne, C. Laffra, Official Eclipse 3.0 FAQs, Addison Wesley Professional, 2004 [6] Javamagazin eclipse special Herbst