Tipps & Tricks: Wie migriere ich existierende Anwendungen nach Eclipse 4.2?

Hartmut Schlosser

Die Veröffentlichung von Eclipse Juno steht kurz bevor. Der Release Train mit seinen 72 angeschlossenen Projekten soll am 27. Juni einlaufen. Bekanntlich basieren diese Projekte zum ersten Mal auf der neuen Eclipse-Plattform der 4.x-Entwicklungslinie, die ein neues Programmiermodell auf der Basis von Services, Annotationen und Dependency Injection einführt. Eclipse 4.x ist also die Zukunft, und wer daran teilhaben möchte, muss sich mit dem Gedanken beschäftigen, seine eigenen Anwendungen auf die neue Plattform zu migrieren.

Wie man eben dies bewerkstelligt, beschreibt Jonas Helming auf dem EclipseSource-Blog. Vier Optionen stehen zur Verfügung. Zum einen wird es eine Kompatibilitätsschicht geben, mit der viele 3.x-Anwendungen bereits ohne Code-Veränderungen auf der Eclipse-4-Plattform laufen können. Das soll gut bei Projekten funktionieren, die keine internen Workbench APIs verwenden. Lediglich kleine Konfigurationsanpassungen werden dann fällig, da Eclipse 4 die folgenden zusätzlichen Plug-ins benötigt:

org.eclipse.equinox.ds : OSGi Plug-in für Declarative Services

org.eclipse.equinox.event: OSGi Event Broker

org.eclipse.equinox.util: Wird von den ersten beiden benötigt

org.eclipse.e4.ui.workbench.addons.swt: Für zusätzliche Features wie die Minimierung und Maximierung von Parts

Haben Sie die Kompatibilitätsschicht bereits einmal ausprobiert? Erfahrungsberichte über diesen Migrationsweg wären hier interessant zu hören!

Um von den Vorteilen der Eclipse 4-Plattform zu profitieren, muss indes ein anderer Weg gegangen werden. Einerseits können neue Projekte natürlich von vorneherein Gebrauch von den neuen APIs machen. Will man existierende Anwendungen ohne Kompatibilitätsschicht nach Eclipse 4 bringen, müssen viele Komponenten an die neuen Gegebenheiten angepasst werden, d.h. im Fall von Workbench-Komponenten aber zu großen Teilen neu geschrieben werden, da Eclipse 4 hier anders funktioniert.

Die dritte Option besteht in einer Mischung aus den ersten beiden: Man migriert existierende Anwendungen auf Basis der Migrationsschicht, fügt neue Komponenten aber anhand des Eclipse-4-Programmiermodells hinzu. Hier gibt es wieder mehrere Wege, die Jonas auf dem Blog näher erläutert.

Und viertens besteht noch die Möglichkeit, eine Eclipse-4-Anwendung neu zu schreiben und dort einige 3.x-Komponenten wiederzuverwenden. Das sollte besonders bei solchen Komponenten funktionieren, die nicht auf das Workbench API zugreifen.

Welche dieser Optionen man wählt, hängt vom Einzelfall ab – als wichtigsten Kriterium sieht Jonas die Anzahl der existierenden und wiederverwendeten Drittpartei-Komponenten. Hinzufügen kann man wohl auch noch den Grad der Bereitschaft, sich in das neue Programmiermodell einzuarbeiten. Wie steht es bei Ihnen damit? Haben Sie schon Erfahrungen mit Eclipse 4 gesammelt?

Die Migrationsanleitung ist Teil einer Tutorial-Reihe, die es auf dem EclipseSource-Blog zu lesen gibt. Ins Detail geht Jonas Helming zusammen mit seinem Kollegen Maximilian Koegel übrigens im Eclipse Magazin. In ihrer e4-Serie präsentieren die beiden dort Tipps und Tricks rund um den neuen Eclipse-Standard.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.