Weshalb wurden Eclipse-APIs in einer inkompatiblen Weise zwischen 2.1 und 3.0 verändert?
Eclipse 3.0 ist eine Weiterentwicklung von Eclipse 2.1. In einigen wenigen Bereichen konnten wir Eclipse nicht weiterentwickeln und gleichzeitig die vollständige Kompatibilität beibehalten. Die vier wichtigsten Ursachen für die Inkompatibilität sind die Folgenden:
Die Liste der spezifischen Inkompatibilitäten:
Funktioniert ein 2.1-Plug-in in Eclipse 3.0?
Ja, mit Ausnahme einiger weniger Fälle. Wenn ein Plug-in ausschließlich auf Eclipse 2.1-APIs beruht, wird es auch in 3.0 weiter funktionieren. Die wenigen Ausnahmen sind Stellen in APIs, an denen die Umstellung von 2.1 auf 3.0 nicht in einer kompatiblen Weise durchgeführt werden konnte; wenn ein Plug-in eine dieser APIs verwendet, wird es nicht funktionieren.
Mein 2.1-Plug-in verwendet Klassen in internen Paketen. Wird es in Eclipse 3.0 weiter funktionieren?
Wenn ein Plug-in auf internen Klassen oder einem nicht in der Eclipse 2.1-API spezifizierten Verhalten beruht, ist es unmöglich, Aussagen darüber zu treffen, ob das Plug-in in 3.0 funktionieren wird oder nicht. Sie müssen es probieren.
Wie kann ich mein Plug-in in Eclipse 3.0 ausführen, ohne es zu berühren?
Installieren Sie Ihr 2.1-Plug-in in das Unterverzeichnis eclipse/plugins/ eines Eclipse 3.0-basierten Produkts und starten Sie Eclipse erneut. Eclipse wird erkennen, dass es sich um ein nicht konvertiertes 2.1-Plug-in handelt (aufgrund des Headers in der plugin.xml) und führt automatisch Anpassungen durch, um Änderungen an Plattform-Plug-in-Abhängigkeiten und umbenannte Erweiterungspunkte zu kompensieren.
Muss ein 2.1-Plug-in geändert werden, um in Eclipse 3.0 korrekt Kompilierungen durchzuführen?
Ja, in allen Fällen. Zwischen Eclipse 2.1 und 3.0 bestehen bestimmte Unterschiede, aufgrund derer Änderungen für alle weitergeleitete Plug-ins erforderlich sind. Wenn Sie ein Plug-in für 2.1 geschrieben haben und es erneut kompilieren möchten, müssen Sie es auf 3.0 migrieren, bevor Sie es für 3.0 weiterentwickeln können.
Wie können Plug-ins auf Eclipse 3.0 migriert werden?
Nachdem Sie das Plug-in-Projekt in den Eclipse 3.0-Arbeitsbereich geladen (oder importiert) haben, verwenden Sie PDE-Tools > Auf 3.0 migrieren (Projektkontextmenü), um das Inhaltsverzeichnis des Plug-ins in das 3.0-Format umzuwandeln und die Liste der erforderlichen Plattform-Plug-ins und die Verweise auf umbenannte Plattform-Erweiterungspunkte automatisch anzupassen. In den meisten Fällen dürfte der Code des Plug-ins dann erfolgreich kompilieren und ausgeführt werden. Der Code für das Plug-in sollte anschließend geprüft werden, um sicherzustellen, dass er nicht von einem der Bereiche der inkompatiblen API-Änderung abhängt.
Kann davon ausgegangen werden, dass ein Plug-in Fehler oder Warnungen kompiliert, wenn es auf einer API basiert, die inkompatibel geändert wurde?
Nein. Es gibt einige Bereiche von inkompatiblen Änderungen, die nicht vom Java-Compiler markiert werden.
Kann ich ohne Bedenken Warnungen im Code, die auf der Verwendung der veralteten API beruhen, ignorieren?
Ja, kurzfristig. Wenn es möglich ist, werden veraltete APIs als veraltet markiert und weiterverwendet, und nicht ganz gelöscht (obgleich dies nur unter bestimmten Umständen möglich ist). Während in der Regel das Löschen veralteter APIs nicht dringlich ist, bedeutet die Tatsache, dass eine API nun als veraltet betrachtet wird, vielmehr, dass es eine bessere Möglichkeit für den Vorgang gibt. Die Verwendung von veralteten APIs durch ein Plug-in sollte so schnell wie möglich verhindert werden.
Kann ich das resultierende binäre Plug-in noch in Eclipse 2.1 installieren und ausführen, nachdem ich mein Plug-in auf Eclipse 3.0 migriert habe?
Nein. Dies wird nicht unterstützt und dürfte vermutlich aufgrund der umbenannten Erweiterungspunkte nicht funktionieren.
Welches ist der Zweck von org.eclipse.core.runtime.compatibility?
Der Wechsel in 3.0 zu einer OSGi-basierten Laufzeit führte dazu, dass einige der vorhandenen wichtigen Laufzeit-APIs veraltet sind. In allen möglichen Fällen wurden veraltete APIs in den org.eclipse.core.runtime.*-Paketen zusammen mit der entsprechenden Implementierung von dem org.eclipse.core.runtime-Plug-in zu einem neuen org.eclipse.core.runtime.compatibility-Plug-in versetzt. Standardmäßig hängen neu erstellte Plug-in von org.eclipse.core.runtime ab und sollen ausschließlich nicht veraltete Laufzeit-APIs verwenden. Andererseits hängen vorhandende Plug-ins, die von 2.1 migrieren, standardmäßig von org.eclipse.core.runtime.compatibility ab und können auch die alten APIs verwenden (das org.eclipse.core.runtime.compatibility-Plug-in reexportiert APIs von org.eclipse.core.runtime). Während das org.eclipse.core.runtime.compatibility-Plug-in vermutlich in die Eclipse IDE-Konfigurationen aufgenommen wird, ist es überflüssig, es in auf RCP-Konfigurationen basierende Produkte aufzunehmen.
Welches ist der Zweck von org.eclipse.ui.workbench.compatibility?
org.eclipse.ui.workbench.compatibility ist ein Plug-in-Fragment, das eine bessere Binärkompatibilität für 2.1-Plug-ins, die auf einem Eclipse 3.0-basierten Produkt ausgeführt werden, bietet. In 3.0 wurden sechs Methoden mit einer expliziten Abhängigkeit von IFile oder IMarker von der org.eclipse.ui.IWorkbenchPage-Schnittstelle entfernt, um die Workbench klar vom Arbeitsbereich und den Ressourcen zu trennen. Das Fragment org.eclipse.ui.workbench.compatibility führt die Anordnung zur Rückführung dieser Methoden aus, sodass vorhandende 2.1-Plug-ins ohne Veränderung ausgeführt werden können. Dabei ist jedoch zu beachten, dass Plug-ins, die auf 3.0 migriert werden und auf die verschobenen Methoden verweisen, Kompilierungsfehler aufweisen, die (nur) durch den Aufruf der Ersatzmethoden, die sich nun in org.eclipse.ui.ide.IDE befinden, gelöst werden können..
Die betreffenden IWorkbenchPage-Methoden sind: openEditor(IFile), openEditor(IFile, Zeichenfolge), openEditor(IFile, Zeichenfolge, Boolesch), openEditor(IMarker), openEditor(IMarker, Boolesch) und openSystemEditor(IFile).