Main

Die Grundlagen von Eclipse wurden vor 10 Jahren von IBM als Grundlage ihres WebSpheres Application Developers initiiert.
Bei IBM erkannten man schnell die Möglichkeiten die Eclipse als OpenSource Projekt Entwicklern bieten könnte und gründeten im Jahre 2001 mit weiteren Mitstreitern (z.B. Borland, SuSe, RedHat, TogetherSoft...) das Eclipse Konsortium.
Kurz nach der Entstehung kapselte sich das Konsortium von den Mutterfirmen ab und nahm weitere Mitglieder auf. Heute besteht das Konsortium aus etwa 40 Firmen darunter auch so prominente Namen wie Fujitsu, Hitachi und HP.

Alle Mitglieder des Eclipse Konsortium unterzeichneten die Common Public License, welche die OpenSource Eigenschaft von Eclipse garantiert. Das bedeutet, das alle Quellcodes von Eclipse offen liegen und von Entwicklern eingesehen und weiterbenutzt werden können.

Die Quellcodes sind in JAVA entwickelt, was zu einem weiteren wichtigen Punkt der Eclipse Philosophie führt, der Plattformunabhängigkeit.

Was ist Eclipse

Nach den Definitionen von IBM ist Eclipse folgendes:
'The Eclipse Plattform is an IDE for anything, and for nothing in particular. (IBM Eclipse White Paper)'

Also so etwas wie die Eierlegendewollmilchsau:

Genaugenommen besteht Eclipse selbst nur aus einem sehr kleinen Funktionskern der Erweiterungsmöglichkeiten bereitstellt, diese Erweiterungen definieren dann was Eclipse ist.
Eclipse ist sozusagen eine Art Betriebssystem in das man über PlugIn Schnittstellen jegliche Anwendung einhängen kann, hauptsächlich für die Softwareentwicklung aber eben nicht nur. Man hat dazu die Möglichkeit diese Anwendungen direkt mit Eclipse selbst zu erstellen.
Dieses Konzept hat den Vorteil dass man sich sein Eclipse nach seinen eigenen Bedürfnissen zusammenstellen bzw. selbst bauen kann.
Man kann also für die C++ Entwicklung einen C++ Editor, eine C++GUI Entwicklung, eine Grafikanwendung und ein Soundeditor einbauen bzw. selbst bauen. Oder das gleiche für Smalltalk. Wenn man will ist es aber auch möglich z.B. Spiele als Eclipse PlugIns zu entwicklen und unter Eclipse zu spielen.

Die Architektur von Eclipse

Ein Grafischer Überblick über die Architektur von Eclipse:

Arbeitsumgebung

Eclipse stellt einen Workspace zur verfügung. Dieser wird durch ein Verzeichnis auf der Festplatte, mit dem Namen des Workspaces, und Unterverzeichnissen repräsentiert. In meinem Workspace werden alle möglichen Ressourcen/Dateien abgelegt, die man zum arbeiten an einem Projekt benötigt (z.B. Quellcodes, Kompilierte Dateien, Bilder ...).

VCM

Eclipse ermöglicht die Entwicklung im Team mit einem im Netz liegenden Repositorium. Dazu wurde das bekannte Versionsverwaltungstool CVS als PlugIn implementiert. Es können gleichzeitig mehrere Repositorien verwaltet werden, d.h. es kann gleichzeitig an mehreren Projekten gearbeitet werden. Eine einmal ausgecheckte Source wird dann für die anderen Teammitglieder zur Bearbeitung gesperrt. Jede Source eines jeden Repositoriums besitzt eine eigene Historie, die man sich vom eigenen Client aus ansehen kann. Dort werden neben dem Datum, Autoren usw. auch Kommentare hinterlegt, aus denen hervorgehen sollte, welche Änderungen vorgenommen wurden.

Für die Arbeit mit der Versionsverwaltung steht eine eigene Perspektive zur Verfügung. Andere Versionsverwaltungstools als CVS können als weitere PlugIns registriert und der Perspektive hinzugefügt werden.

Workbench - Userinterface

Das Userinterface ist durch den Benutzer mittels PlugIns erweiterbar/veränderbar (es können sowohl Komponenten wie Menüs, Editoren und Fenster als auch Aktionen hinzugefügt werden). Die Workbench an sich kann mehrere Perspektiven besitzen, zwischen denen der User einfach wechseln kann. Verschiedene Perspektiven vermitteln dem Benutzer verschiedene Informationen auf unterschiedlichen Ebenen.

Das Standard Eclipse wird schon mit einigen vordefinierten Perspektiven ausgeliefert, z.B. zur Java Entwicklung, zur Entwicklung von PlugIns oder zum kommunizieren über CVS.

SWT/JFace

Durch die Ähnlichkeit der Bezeichnung mit dem bekannten JAVA/AWT ist auch sofort die Bedeutung des SWT erkennbar. Es definiert Bausteine zum Aufbau graphischer Benutzeroberflächen (d.h. Buttons, Frames, Menus,..., sog. "Widgets") für Eclipse. Der Unterschied zum AWT liegt in der Plattformunabhängigkeit des SWT (d.h. es greift auf keinerlei betriebssystemeigene Komponenten zu) sowie der Möglichkeit, komplexe Widgets wie Bäume oder Tabellen darzustellen. Im folgenden nun Screenshots der Oberflächen unter Windows und LINUX (man erkennt die optische Gleichheit).

JFace ist ein Toolkit, dessen Methoden und Funktionen auf den SWT-Widgets aufbauen. So legen diese Methoden beispielsweise Schrifttypen und -größen fest, speichern Benutzereinstellungen für einzelne Komponenten oder stellen ein "progress reporting" für lang andauernde Operationen zur Verfügung.

Plugins

Ein PlugIn ist ein Modul, dass mit dem Gesamtsystem oder anderen PlugIns über wohl definierte Schnittstellen in einer wohl definierten Art und Weise kommuniziert beziehungsweise interagiert.
Diese Plugins machen die Art meines Eclipses aus. Standardmäßig mitgeliefert ist zum Beispiel das JDT PlugIn zum entwickeln von JAVA Anwendungen.
Eclipse definiert wie diese PlugIns aussehen müssen und wie sie mit dem System interagieren bzw. eingehängt werden.

Help

Wegen der Erweiterungsmöglichkeiten der Funktionalität von Eclipse durch PlugIns, muss auch die Online-Hilfe erweiterungsfähig sein. Alle PlugIn-Entwickler können demnach ihren PlugIns HTML- und XML-Files beilegen, die die Funktionsweise der neuen Komponente beschreiben. Dabei übernehmen die XML-Dateien die Navigation innerhalb der Hilfe und die HTML-Dateien die Beschreibung der Funktionen. Die Hilfe muss also nur nach den XML-Dateien suchen, die in entsprechenden Verzeichnissen der PlugIn-Klassen abgelegt werden müssen. Die wichtigste Aufgabe der Help-Files ist die Beschreibung der eigenen sog. Extension Points, auf die von anderen PlugIns aus zugegriffen werden kann und die Erweiterbarkeit des eigenen PlugIns beschreiben.