Sobald alles heruntergeladen und auf einer geeigneten Workstation installiert ist, kann Eclipse gestartet werden, um nach dem ersten Kennenlernen neue Projekte (z.B. ein neues Plug-in-Projekt) in Angriff zu nehmen. Die Benutzeroberfläche ist dem Benutzer schnell vertraut, zumal die Projekt- und Navigations- Views Hilfestellung beim Erstellen und Managen von Embedded- und hostresidenten Projekten leisten. Anders als bei traditionellen Embedded- und Host-Entwicklungssystemen wird bei Eclipse ein und dieselbe Umgebung zum Erstellen der Embedded-Systems-Tools und der Embedded-Systeme selbst verwendet. Der Unterschied liegt in dem Toolsatz, der als Plug-in in das Framework eingefügt wird.
Für die Entwicklung eines Plug-in (auch wenn dieses im Kontext des Embedded- Tools-View benutzt wird) dient das native Java-Development- Toolkit, begleitet vom SWT und den JFace- Toolkits und Libraries. Damit wird Eclipse zu einer »Self- Hosting«-Umgebung. Die Entwicklung eines Eclipse- Plug-ins gliedert sich in mehrere Arbeitsgänge, die alle dokumentiert sind und von Wizards (Assistenten) in der Eclipse-Umgebung unterstützt werden.
Schritt 1 besteht in der Einrichtung eines Plug-in- Projekts. Hierzu wird der neue Projekt- Wizard in Eclipse verwendet und im Menü die Option »Plug-in Project« gewählt. Mit dem Wizard legt der Anwender anschließend den Ort des Plug-ins sowie seine Struktur und seinen Inhalt fest. Danach besteht die Option zur Verwendung einer Vorlage (»Template«) zum Generieren eines voll funktionsfähigen Plug-in. Neben einer »Hello World«- Demo erlauben diese Templates das Anfertigen von Plug-ins mit einem Multi- Page-Editor, einem Editor, einem Pop-up-Menü, einer Property-Seite, einem View (zum Erstellen eines Workbench View, wie beschrieben) und eines Plug-ins mit Perspective-Erweiterungen. Ist eine dieser Optionen gewählt, fragen weitere Wizards bestimmte Merkmale ab, die in diesen Templates als Optionen verfügbar sind. Sobald im Wizard der »Finish«-Button betätigt wird, generiert Eclipse den Code zu den im Wizard gewählten Optionen.
In Schritt 2 wird die Eclipse- Umgebung zum Prüfen und Modifizieren des generierten Codes benutzt. Den Anfang in diesem Prozess bildet die Untersuchung des Plug-in-Manifests mit dem entsprechenden Editor. Das »Plug-in Manifest« offenbart, in welcher Beziehung das in der Entwicklung befindliche Plug-in zu den übrigen Plug-ins im System steht. Dies hat ganz besondere Bedeutung, da alle übrigen Bestandteile des Plug-in-Produkts als Plug-ins realisiert sind. Nach Prüfung des Manifests entweder im visuellen Editor oder durch Untersuchung des XMLQuellcodes zu dem Manifest dieses Plug-ins (ebenfalls im Editor verfügbar) kann der Code für den vom Template erzeugten View gesichtet und editiert werden. Auf diese Weise lassen sich neue Features in den zu diesem Plug-in gehörenden View integrieren. In diesem Stadium arbeitet der View noch mit Musterdaten, die im Template generiert werden und eine gute Grundlage für die erstmalige Verwendung des Plug-ins darstellen.
<< vorherige Seite
1 | 2 | 3| 4| 5| 6| 7
nächste Seite >>
Die Workbench stellt die Personalisierung der Benutzeroberflächen bereit. Dieses Paradigma stützt sich auf Editoren, Ansichten (»Views«) und »Perspectives«. Ein Workbench- Fenster besteht aus Views und Editoren, während es sich bei einer Perspective um eine bestimmte Auswahl und Zusammenstellung von Views und Editoren handelt. Editoren ermöglichen dem Anwender das Öffnen, Editieren und Abspeichern von Objekten (in einem Embedded- System handelt es sich bei diesen Objekten meist um C- und C++-Quelldateien). Die Plattform stellt einen standardmäßigen Texteditor zur Verfügung. Das CDT-Projekt bietet eine speziellere C/C++-Kontextversion. Andere kommerzielle Produkte bringen eigene Editoren (z.B. UML-Editoren) mit, und daneben gibt es auch eigenständige kommerzielle Editoren (z.B. »Slick- Edit«). Views dienen zur Ausgabe von Informationen über ein Objekt, an dem der Anwender arbeitet.