Inkompatibilitäten zwischen Eclipse 2.1 und 3.0

Eclipse wurde in inkompatibler Weise von 2.1 zu 3.0 verändert, was sich auf die Plug-ins auswirkt. Die folgenden Abschnitte beschreiben die Bereiche, die geändert wurden, und enthalten Anweisungen für die Migration eines 2.1-Plug-ins auf 3.0. Beachten Sie, dass Sie nur hier nachsehen müssen, wenn Sie Probleme beim Ausführen Ihres 2.1-Plug-ins auf 3.0 haben.

  1. Plug-in-Manifestversion
  2. Umstrukturierung des Plug-ins der Benutzerschnittstelle der Plattform
  3. Umstrukturierung des Plug-ins für die Kernlaufzeit der Plattform
  4. Entfernen des Xerces-Plug-ins
  5. In Eclipse 3.0 laufen mehr Vorgänge gleichzeitig ab.
  6. Editoren auf IFiles öffnen
  7. Editor zu Markierung
  8. Startprogramm des Editors
  9. Editorregistrierung
  10. Hilferegistrierung der Workbench-Markierung
  11. Dokumentprovider für Texteditor
  12. Texteditoren
  13. Automatische Anmerkungsunterstützung
  14. Sicht 'Konsole'
  15. Listenerfunktion für Java-Unterbrechungspunkt
  16. Zugriff auf Zwischenablage im Benutzerschnittstellenthread
  17. Tastenereignisse
  18. Tabulatorverwendung von Steuerelementen
  19. Auswahl der Ereignisreihenfolge in der SWT-Tabelle und Strukturfensterobjekten
  20. Neue Wertigkeit in Status der Objekte
  21. Erstellungsbezogene Hinweise zur Änderung von Ressourcen
  22. Zwischenhinweise während Arbeitsbereichsoperationen
  23. Erweiterungen von URL-Datenstromsteuerroutinen
  24. Reihenfolge des Klassenladeprogramms
  25. Nicht eingerichtete Schutzdomäne für Klassenladeprogramm
  26. PluginModel-Objektumsetzung
  27. Unvollständige Implementierung von ILibrary
  28. Ungültige Annahmen in Bezug auf die Form von URLs
  29. BootLoader-Methoden versetzt/gelöscht
  30. Plug-in-Export umfasst nicht automatisch die JARs der Plug-ins
  31. Laufzeit-API erneut exportieren
  32. Plug-in-Parsing-Methoden auf Plattform
  33. Durch Fragmente bereitgestellte Plug-in-Bibliotheken
  34. Änderungen an Erstellungsscripts
  35. Änderungen an PDE-erstellter Ant-Task
  36. Änderungen an eclipse.build Ant-Task
  37. Änderungen an eclipse.fetch Ant-Task
  38. Ersetzen von install.ini

1. Plug-in-Manifestversion

Der Header der Manifestdateien für Plug-ins (und Plug-in-Fragmente) wurde geändert, um eine neue Zeile einzufügen, die die entsprechende Plug-in-Manifestversion identifiziert. Vor 3.0 hatten die Plug-ins keine dieser <?eclipse ...?> Zeilen; ab 3.0 müssen sie stets eine haben. Mit dieser Änderung kann die Eclipse-Laufzeit die Plug-ins vor 3.0, die nicht auf 3.0 portiert wurden, zuverlässig erkennen. Damit steht eine größere Binärkompatibilität für diese Plug-ins zur Verfügung. Dies ist die allgemeine Form der Datei plugin.xml (fragment.xml ist ähnlich):

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
    ...
</plugin>

Von PDE 3.0 erstellte Plug-in-Manifeste haben automatisch diese Form. Es wird nachdrücklich empfohlen, das PDE-Plug-in-Migrationstool zu verwenden. Es setzt die genannte Zeile automatisch in das 2.1-Plug-in und diePlug-in-Fragmente ein und behandelt viele der hier beschriebenen Änderungen.

Falls Sie diese Anweisung zu plugin.xml hinzufügen (manuell oder mithilfe von PDE), muss die Datei auch aktualisiert werden, um das Plug-in, von dem sie abhängt, explizit aufzulisten. Beispielsweise waren vor Eclipse 3.0 Abhängigkeiten von org.eclipse.core.runtime und org.eclipse.core.boot implizit. Mit 3.0 ist org.eclipse.core.boot nicht mehr erforderlich und die Entwickler müssen org.eclipse.core.runtime oder org.eclipse.core.runtime.compatibility (oder keine von beiden) je nach Fall auswählen.

Hinweis: Dies ist eine der Inkompatibilitäten, die keinen Einfluss darauf hat, wie binäre 2.1-Plug-ins von Eclipse 3.0 ausgeführt werden.

2. Umstrukturierung des Plug-ins der Benutzerschnittstelle der Plattform

Das Plug-in org.eclipse.ui, das üblicherweise das Plug-in der Benutzerschnittstelle der Hauptplattform war, stellt nun lediglich die API und die Erweiterungspunkte für die generische (d. h. nicht IDE-spezifische) Workbench zur Verfügung. Optionale und IDE-spezifische Erweiterungspunkte wurden zu anderen Plug-ins versetzt.

Diese Änderung hat zweierlei Auswirkungen: (1) die versetzten org.eclipse.ui-Erweiterungspunkte haben neue Erweiterungspunkt-IDs; und (2) die Liste der erforderlichen Plug-ins hat sich geändert.

Die org.eclipse.ui-Erweiterungspunkte in der folgenden Tabelle wurden in andere Plug-ins versetzt, wodurch ihre Erweitungspunkt-IDs geändert wurden. Falls ein vorhandenes Plug-in eine Erweiterung für versetzte Erweiterungspunkte zur Verfügung stellt, muss der Verweis im Attribut "point" des Elements <Erweiterung> in der Plug-in-Manifestdatei geändert werden, sodass er sich auf die entsprechenden neuen Erweiterungspunkt-IDs bezieht. Das PDE Plug-in-Migrationstool führt diese Korrekturen durch.

Hinweis: Dies ist eine der Inkompatibilitäten, die keinen Einfluss darauf hat, wie binäre 2.1-Plug-ins von Eclipse 3.0 ausgeführt werden. Die Eclipse 3.0-Laufzeit ermittelt Plug-ins aus Versionen vor 3.0 (durch das Fehlen der vorstehend genannten Zeile <?eclipse version="3.0"?> im Plug-in-Manifest) und kompensiert diese Erweiterungspunkte und die Änderungen der Plug-in-Abhängigkeit automatisch.

Alte Erweiterungspunkt-ID

Neue Erweiterungspunkt-ID

org.eclipse.ui.markerHelp org.eclipse.ui.ide.markerHelp
org.eclipse.ui.markerImageProviders org.eclipse.ui.ide.markerImageProviders
org.eclipse.ui.markerResolution org.eclipse.ui.ide.markerResolution
org.eclipse.ui.projectNatureImages org.eclipse.ui.ide.projectNatureImages
org.eclipse.ui.resourceFilters org.eclipse.ui.ide.resourceFilters
org.eclipse.ui.markerUpdaters org.eclipse.ui.editors.markerUpdaters
org.eclipse.ui.documentProviders org.eclipse.ui.editors.documentProviders
org.eclipse.ui.workbench.texteditor.
markerAnnotationSpecification
org.eclipse.ui.editoren.markerAnnotationSpecification

Die folgenden Tabellen führen die früher vom Plug-in org.eclipse.ui bereitgestellten API-Pakete auf, die in andere Plug-ins versetzt wurden. (Die Namen der API-Pakete, -Klassen, -Felder und -Methoden haben sich nicht geändert.) In einigen Fällen sind die API-Pakete nun in mehrere Plug-ins aufgeteilt. Da die für ein bestimmtes Plug-in sichtbaren API-Klassen durch die Liste der erforderlichen Plug-ins für dieses Plug-in festgelegt werden, ist für diese Änderungen möglicherweise die Anpassung der "<erforderlichen>" Elemente in einem vorhandenen Plug-in-Manifest erforderlich, um den Zugriff auf die API-Klasse wiederherzustellen.

Diese Änderung betrifft nur Plug-ins, die von dem Plug-in org.eclipse.ui abhängen (d. h. die <import plugin="org.eclipse.ui"/> im Abschnitt <erforderlich> des Plug-in-Manifests enthalten); alle anderen Plug-ins sind nicht betroffen. Falls das Plug-in betroffen ist, müssen Sie möglicherweise das Element <import> ändern oder zusätzliche <import>-Elemente hinzufügen, sodass alle API-Klassen, die Ihr Plug-in benötigt, vorhanden sind. Wir empfehlen nachdrücklich, dass für Plug-ins nur Abhängigkeiten angegeben werden, die dieses Plug-in tatsächlich verwendet. Die Angabe unnötiger Abhängigkeiten reduziert die Laufzeitleistung, da das Java-Klassenladeprogramm in allen Abhängigkeiten nach Klassen suchen muss. (Das PDE Plug-in-Migrationstool korrigiert die Abhängigkeiten und ist bei der Ermittlung der Mindesteinrichtung hilfreich.)

API-Paket

2.1-Plug-in

Entsprechende(s) 3.0-Plug-in(s)

org.eclipse.jface.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.ui org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.actions org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.dialogs org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.editors.* org.eclipse.ui org.eclipse.ui.editor
org.eclipse.ui.model org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.part org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.texteditor org.eclipse.ui org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors
org.eclipse.ui.texteditor.* org.eclipse.ui org.eclipse.ui.workbench.texteditor
org.eclipse.ui.views.bookmarkexplorer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.contentoutline org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.markers org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.navigator org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.properties org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.tasklist org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.datatransfer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.newresource org.eclipse.ui org.eclipse.ui.ide

3. Umstrukturierung der Plug-ins für die Kernlaufzeit der Plattform

Die Eclipse 3.0 Plattformlaufzeit basiert auf OSGi, sodass Änderungen an der Struktur der beiden Plug-ins für die Plattformlaufzeit, org.eclipse.core.runtime und org.eclipse.core.boot, notwendig sind.

Ein neues org.eclipse.core.runtime.compatibility-Plug-in stellt eine Implementierungsbrücke zwischen den alten und neuen APIs zur Verfügung und ist der neue Ausgangspunkt für viele veraltete APIs, die sich früher in org.eclipse.core.runtime und org.eclipse.core.boot befanden. Die Erweiterungspunkte der Plattformlaufzeit sind von der Umstrukturierung nicht betroffen.

Bei der Migration des vorhandenen Plug-ins auf 3.0 muss das Plug-in-Manifest aktualisiert werden, um die neue Struktur der Plug-ins der Eclipse Plattformlaufzeit wiederzugeben. Das Migrationstool für das PDE-Plug-in-Manifest fügt eine Abhängigkeit zu org.eclipse.core.runtime.compatibility hinzu, falls dies erforderlich ist.

Beachten Sie bitte, dass, falls Sie Ihr Plug-in als 3.0 kennzeichnen (mithilfe von <?eclipse version="3.0"?>) und Ihr Plug-in eine Plug-in-Klasse definiert, Sie entweder explizit <Plug-in importieren="org.eclipse.core.runtime.compatibility"/> für das Plug-in-Manifest festlegen oder sicherstellen müssen, dass die Plug-in-Klasse den Standardkonstruktor definiert.

Hinweis: Dies ist eine der Inkompatibilitäten, die keinen Einfluss darauf hat, wie binäre 2.1-Plug-ins von Eclipse 3.0 ausgeführt werden. Die Eclipse 3.0-Laufzeit ermittelt Plug-ins aus Versionen vor 3.0 (durch das Fehlen der Zeile <?eclipse version="3.0"?> im Plug-in-Manifest) und kompensiert diese Änderungen an der Plattformlaufzeit automatisch.

4. Entfernen des Xerces-Plug-ins

Das Plug-in org.eclipse.xerces ist nicht mehr erforderlich und wurde gelöscht. Die XML-Parsing-Unterstützung ist in J2SE 1.4 integriert und das Vorhandensein des Xerces-Plug-in führt zu Konflikten mit dem Klassenladeprogramms. Die API-Pakete javax.xml.parsers, org.w3c.dom.* und org.xml.sax.*, die früher von dem Plug-inorg.eclipse.xerces-Plug bereitgestellt wurden, sind nun über die J2SE-Bibliotheken verfügbar.

Falls Ihr Plug-in das Plug-in org.eclipse.xerces benötigt, müssen Sie Ihr Plug-in-Manifest ändern, um diese angegebene Abhängigkeit zu entfernen. Sobald Sie dies durchgeführt haben, sollte der Code des Plug-ins die Kompilierung durchführen und ohne weitere Änderungen ausgeführt werden.

Für ein binäres 2.1-Plug-in mit einer angegebenen Abhängigkeit von dem Plug-in org.eclipse.xerces fehlt bei der Ausführung einer Eclipse 3.0-Standardkonfiguration eine Vorbedingung. Das Plug-in wird daher nicht aktiviert.

5. In Eclipse 3.0 laufen mehr Vorgänge gleichzeitig ab.

Vor Eclipse 3.0 wurde Eclipse hauptsächlich über einen Einzelpfad ausgeführt. Die meisten API-Methoden und Erweiterungspunkte wurden entweder in dem Benutzerschnittstellenthread oder in einem von einem Fortschrittsdialog geöffneten Thread betrieben, der den Benutzerschnittstellenthread blockierte. Die meisten Plug-in-Autoren hatten keine Bedenken hinsichtlich der Threadsicherheit. Es wurde lediglich sichergestellt, dass die gesamten Benutzerschnittstellenaktivitäten in dem Benutzerschnittstellenthread stattfanden. In Eclipse 3.0 besteht im Allgemeinen ein umfassenderer gemeinsamer Zugriff. Viele Operationen finden nun im Hintergrundthread statt, wo sie gleichzeitig mit anderen Threads, einschließlich dem Benutzerschnittstellenthread ausgeführt werden. Alle Plug-ins, deren Codes in einem Hintergrundthread ausgeführt werden, müssen nun Informationen über die Threadsicherheit ihres Codes erhalten.

Zusätzlich zu den Plug-ins, die explizit Operationen mithilfe der org.eclipse.core.runtime.jobs-API ausführen, sind verschiedene Plattform-API-Funktionen und Erweiterungspunkte vorhanden, die den Hintergrundthread verwenden. Für Plug-ins, den den Hook dieser Funktionen verwenden, muss sichergestellt werden, dass ihr Code threadsicher ist. In der folgenden Tabelle werden die APIs und Erweiterungspunkte zusammengefasst, deren Code in Eclipse 3.0 ganz oder teilweise in einem Hintergrundthread ausgeführt wird:

Erweiterungspunkt oder API-Klasse

Hinweise

org.eclipse.core.runtime.IRegistryChangeListener Neu in Eclipse 3.0, wird im Hintergrund ausgeführt
org.eclipse.core.resources.IResourceChangeListener AUTO_BUILD-Ereignisse jetzt im Hintergrund
org.eclipse.core.resources.builders (Erweiterungspunkt) Automatische Erstellung jetzt im Hintergrund
org.eclipse.core.resources.ISaveParticipant SNAPSHOT jetzt im Hintergrund
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (Erweiterungspunkt) Neu in Eclipse 3.0, wird im Hintergrund ausgeführt
org.eclipse.ui.decorators (Erweiterungspunkt) Bereits in Eclipse 2.1 im Hintergrund
org.eclipse.ui.startup (Erweiterungspunkt) Bereits in Eclipse 2.1 im Hintergrund
org.eclipse.team.core.org.eclipse.team.core.repository (Erweiterungspunkt) Zahlreiche Operationen jetzt im Hintergrund
org.eclipse.team.ui.synchronizeParticipants (Erweiterungspunkt) Neu in Eclipse 3.0, wird im Hintergrund ausgeführt
org.eclipse.debug.core.launchConfigurationTypes (Erweiterungspunkt) Jetzt Ausführung im Hintergrund
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD wird jetzt im Hintergrund ausgeführt, POST_RECONCILE wurde bereits im Hintergrund ausgeführt

Es stehen verschiedene Strategien zur Verfügung, um die Threadsicherheit herzustellen. Auf einfache Weise kann dies gelöst werden, indem sichergestellt wird, dass alle Vorgänge im Benutzerschnittstellenthread ausgeführt werden. Dazu muss die serialisierte Ausführung sichergestellt werden. Dies ist die übliche Strategie für Plug-ins von Benutzerschnittstellen, die keine CPU-intensive Verarbeitung ausführen. Dabei muss das Display.syncExec inhärente Risiko des gegenseitigen Sperrens beachtet werden. Display.asyncExec ist im Allgemeinen sicherer, da es kein Risiko des gegenseitigen Sperrens mit sich bringt, allerdings geht die genaue Kontrolle bei der Ausführung des Codes verloren.

Sie können auch die folgenden Techniken verwenden, um einen Thread sicher zu machen:

6. Editoren auf IFiles öffnen

Die folgenden Methoden wurden aus der Schnittstelle org.eclipse.ui.IWorkbenchPage gelöscht. IWorkbenchPage ist in der generischen Workbench deklariert, doch die Methoden sind inhärent ressourcenspezifisch.

Clients dieser IWorkbenchPage.openEditor-Methoden sollten stattdessen die entsprechenden öffentlichen statischen Methoden aufrufen, die in der Klasse org.eclipse.ui.ide.IDE (im Plug-in org.eclipse.ui.ide) angegeben sind.

Clients dieser IWorkbenchPage.openSystemEditor(IFile)-Methode sollten die IFile mithilfe der neuen FileEditorInput(IFile) in ein IEditorInput umwandeln und anschließend die Methode openEditor(IEditorInput,Zeichenfolge) aufrufen, d. h. die Datei page.openSystemEditor(Datei) als page.openEditor(neue FileEditorInput(Datei), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID) umschreiben. Hinweis: Clients, die die Editor-ID IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID verwenden, müssen eine Editoreingabe weitergeben, die org.eclipse.ui.IPathEditorInput implementiert (wird von FileEditorInput ausgeführt).

Hinweis: Dies ist eine der Inkompatibilitäten, die keinen Einfluss darauf hat, wie binäre 2.1-Plug-ins von Eclipse 3.0 ausgeführt werden. Eclipse 3.0 umfasst einen binären Laufzeitkompatibilitätsmechanismus, der sicherstellt, dass vorhandene 2.1-Plug-in-Binärobjekte, die eine der gelöschten openEditor- oder openSystemEditor-Methoden verwenden, trotz der API-Änderung wie in 2.1 weiter ausgeführt werden. (Die gelöschten Methoden werden effektiv mit dem Fragment org.eclipse.ui.workbench.compatibility "hinzugefügt back".)

7. Editor zu Markierung

Die folgende Methode wurde aus der Schnittstelle org.eclipse.ui.IEditorPart gelöscht. IEditorPart ist in der generischen Workbench angegeben, doch die Methode ist inhärent ressourcenspezifisch.

Die entsprechenden Methoden wurden auch aus den Klassen in dem Paket org.eclipse.ui.part gelöscht, das IEditorPart, insbesondere EditorPart, MultiEditor, MultiPageEditorPart und MultiPageEditor implementiert. 

Clients, die diese Methode aufrufen, sollten stattdessen testen, ob die Editorkomponente org.eclipse.ui.ide.IGotoMarker (im Plug-in org.eclipse.ui.ide) implementiert oder sich anpasst, und falls dies der Fall ist, gotoMarker(IMarker) aufrufen. Die IDE-Klasse verfügt für diesen Zweck über eine Komfortmethode: IDE.gotoMarker(Editor, Markierung);

Clients, die einen Editor implementieren, der sich selbst aufgrund der IMarker-Information positionieren kann, sollten org.eclipse.ui.ide.IGotoMarker implementieren oder daran anpassen.

Da gotoMarker(IMarker) die einzige Methode von IGotoMarker ist und dieselbe Kennung und Spezifikation wie die alte IEditorPart.gotoMarker(IMarker) verwendet, können sich vorhandene Editorimplementierungen an diese Änderung einfach durch die Aufnahme von IGotoMarker in die Klausel 'implements' der Klassendefinition anpassen.

Ein binäres 2.1-Plug-ins mit einem Code, der diese Methode aufruft, erhält eine klassenverknüpfende Fehlerausnahmebedinung beim Ausführen einer Eclipse 3.0-Standardkonfiguration.

8. Editorstartprogramm

Die Schnittstelle org.eclipse.ui.IEditorLauncher der Editorschnittstelle wird durch ein Plug-in implementiert, das externe Editoren zur Verfügung stellt. Die folgende Methode wurde aus dieser Schnittstelle entfernt. IEditorLauncher ist in der generischen Workbench angegeben, doch die Methode ist inhärent ressourcenspezifisch.

Sie wurde ersetzt durch

Clients, die IEditorLauncher.open(Datei) aufrufen, sollten stattdessen IEditorLauncher.open(file.getLocation()) aufrufen. Clients, die diese Schnittstelle implementieren, sollten ihre Implementierung von open(IFile) durch eine für open(IPath) ersetzen (oder erweitern).

Ein binäres 2.1-Plug-ins mit einem Code, der diese Methode aufruft, erhält eine klassenverknüpfende Fehlerausnahmebedinung beim Ausführen einer Eclipse 3.0-Standardkonfiguration.

9. Editorregistrierung

Die folgenden Methoden wurden aus der Schnittstelleorg.eclipse.ui.IEditorRegistry gelöscht. IEditorRegistry ist in der generischen Workbench angegeben, doch die Methoden sind inhärent ressourcenspezifisch.

Clients, die getEditors(Datei) oder getImageDescriptor(Datei)aufrufen, sollten die "Zeichenfolge"-äquivalenten Methoden aufrufen: Clients, die setDefaultEditor(IFile-Datei, Zeichenfolge editorId) und getDefaultEditor(IFile-Datei) aufrufen, sollten stattdessen die entsprechenden öffentlichen statischen Methoden, die in der Klasse org.eclipse.ui.ide.IDE (im Plug-in org.eclipse.ui.ide) angegeben sind, aufrufen: Auch der API-Vertrag für die Methode IEditorRegistrygetDefaultEditor() wurde geändert. Diese Methode, die nun auch veraltet ist, gibt immer den externen Editordeskriptor des Systems zurück. Diese Änderung wirkt sich auf Clients aus, die davon ausgehen, dass der zurückgegebene Standardeditor ein Texteditor ist.

Es sind neue Konstanten vorhanden, die den externen Editor des Systems und die integrierten Editorkennungen des Systems (SYSTEM_EXTERNAL_EDITOR_ID und SYSTEM_INPLACE_EDITOR_ID) darstellen. Diese beiden Editoren erfordern eine Editoreingabe, die org.eclipse.ui.IPathEditorInput implementiert oder anpasst. Beachten Sie, dass der integrierte Editordeskriptor nicht in Eclipse-Konfigurationen vorhanden ist, die keine integrierte Bearbeitung unterstützen.

10. Hilferegistrierung der Workbench-Markierung

Die folgende Methode wurde aus der Schnittstelle org.eclipse.ui.IWorkbench gelöscht. IWorkbench ist in der generischen Workbench angegeben, doch die Methode ist inhärent ressourcenspezifisch.

Clients von IWorkbench.getMarkerHelpRegistry() sollten stattdessen die öffentliche statische Methode org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (im Plug-in org.eclipse.ui.ide) aufrufen.

Ein binäres 2.1-Plug-ins mit einem Code, der diese Methode aufruft, erhält eine Ausnahmebedingung beim Ausführen einer Eclipse 3.0-Standardkonfiguration.

11. Dokumentprovider für Texteditor

Um org.eclipse.ui.texteditor.AbstractTextEditor von IFile unabhängig zu machen, führt org.eclipse.ui.texteditor.AbstractDocumentProvider das Konzept einer Dokumentprovideroperation (DocumentProviderOperation) und einer Ausführungsfunktion für Operationen von Dokumentprovidern (IRunnableContext) ein. Bei einer Aufforderung zum Ausführen, Zurücksetzen, Speichern oder Synchronisieren erstellt AbstractDocumentProvider Dokumentprovideroperationen und verwendet die Ausführungsfunktion für Operationen, um sie auszuführen. Der ausführbare Kontext kann von Unterklassen über die Methode getOperationRunner bereitgestellt werden. Hier finden Sie eine Zusammenfassung der Änderungen, an die sich die Clients anpassen müssen:

Die AbstractDocumentProvider-Unterklasse org.eclipse.ui.editors.text.StorageDocumentProvider implementiert die Methode getOperationRunner so, dass immer Null zurückgegeben wird. Daher dürften die Unterklassen von StorageDocumentProvider nicht von dieser Änderung betroffen sein.

Die StorageDocumentProvider-Unterklasse org.eclipse.ui.editors.text.FileDocumentProvider implementiert die Methode getOperationRunner, die einen IRunnableContext für die Ausführung der angegebenen DocumentProviderOperations in einer WorkspaceModifyOperation zurückgibt. Die weiterten Änderungen an FileDocumentProvider umfassen:

12. Texteditoren

Änderungen an org.eclipse.ui.texteditor.AbstractTextEditor:

Die AbstractTextEditor-Unterklasse org.eclipse.ui.texteditor.StatusTextEditor stellt die Vergleichselementmethode isErrorStatus(IStatus) zur Verfügung. Unterklassen können überschreiben, um festzulegen, ob ein bestimmter Status als Fehler anzusehen ist oder nicht.

Änderungen an org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:

13. Automatische Anmerkungsunterstützung

Als Teil der Einführung zur automatischen Anmerkungsunterstützung wurden die folgenden Änderungen an Anmerkungen durchgeführt:

        org.eclipse.jface.text.source.Annotation 
        org.eclipse.jface.text.source.AnnotationModel 
        org.eclipse.jface.text.source.AnnotationModelEvent 
        org.eclipse.jface.text.source.IAnnotationModel 
        org.eclipse.jface.text.source.IAnnotationModelListener 
        org.eclipse.jface.text.source.IAnnotationModelListenerExtension

14. Sicht 'Konsole'

Eclipse 3.0 hat eine neue generische Konsolenunterstützung. Die generische Konsole ist verfügbar unter dem Fenster > Sicht anzeigen > Basis > Konsole, und wird von Eclipse Debug und Ant-Integration verwendet.

Die Sicht-ID für die Konsole wurde von org.eclipse.debug.ui.ConsoleView auf org.eclipse.ui.console.ConsoleView geändert. 2.1-Plug-ins, die die Konsole über das Programm öffnen, werden keinen Erfolg haben, da die alte Sicht nicht mehr vorhanden ist.

15. Listenerfunktion für Java-Unterbrechungspunkt

In 3.0 wurden die Rückgabetypen für die Methoden org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) und installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) von Boolesch auf int verändert, um es Listenerfunktionen zu ermöglichen, sich für "gleichgültig" zu entscheiden. In Versionen vor 3.0 konnten die Listenerfunktionen nur "aussetzen" oder "nicht aussetzen" auswählen, wenn ein Unterbrechungspunkt getroffen wurde, und "installieren" oder "nicht installieren" auswählen, wenn ein Unterbrechungspunkt installiert werden sollte. In 3.0 können Listenerfunktionen auch "gleichgültig" für eine dieser Benachrichtigungen auswählen. Damit können Clients nur eine Entscheidung in Situationen treffen, an denen sie Interesse haben. Bei Mitteilungen über "Unterbrechungspunkttreffer" wird der Unterbrechungspunkt ausgesetzt, wenn eine Listenerfunktion "aussetzen" oder alle Listenerfunktionen "gleichgültig"; wählen, und er wird nicht ausgesetzt, wenn mindestens eine Listenerfunktion "nicht aussetzen" und keine Listenerfunktion "aussetzen" wählt. Bei Mitteilungen über "Unterbrechungspunkt installieren" wird der Unterbrechungspunkt installiert, falls eine Listenerfunktion installieren wählt, oder alle Listenerfunktionen "gleichzeitig"; wählen, und er wird nicht installiert, wenn mindestens eine Listenerfunktion "nicht installieren" und keine Listenerfunktion "installieren" wählt. Im Allgemeinen sollten Implementierungselemente DONT_CARE zurückgeben, sofern sie nicht eine ausgeprägte Meinung in der einen oder anderen Weise haben. Es muss beispielsweise beachtet werden, dass die Wahl von "aussetzen" die Wahl einer anderen Listenerfunktion von "nicht aussetzen" überschreibt.

Die Schnittstelle IJavaBreakpointListener wird von Clients implementiert, die Unterbrechungspunkte im Java-Code erstellen oder auf sie reagieren. Vermutlich gibt es neben JDT nur wenige Clients, abgesehen von demjenigen, der das Problem gemeldet hat (Programmfehler 37760, die diese Änderung ausgleichen. Dies ist eine Änderung, die für den vorhandenen Code, der die Schnittstelle IJavaBreakpointListener implementiert, eine Unterbrechung zur Folge hat. Dieser Code muss geändert werden, um einen entsprechenden int-Wert zurückzugeben, bevor er kompiliert oder auf 3.0 ausgeführt wird.

16. Zugriff auf Zwischenablage im Benutzerschnittstellenthread

Vor 3.0 war es den Methoden der SWT-Klasse org.eclipse.swt.dnd.Clipboard stillschweigend gestattet, in anderen als dem Benutzerschnittstellenthread ausgeführt zu werden. Diese Übersicht führte zu Fehlern auf GTK, bei dem das Betriebssystem erfordert, dass alle Zwischenablageinteraktionen im Benutzerschnittstellenthread ausgeführt werden. Die Übersicht wurde früher nicht dargestellt, da viele Anwendungen einpfadig sind und einen Großteil ihrer Tests auf Windows empfangen. Damit die Zwischenablage-API nachhaltig und plattformübergreifend ist, wurden in 3.0 die Spezifikation und die Implementierung aller Zwischenablage-API-Methoden geändert, um eine SWT-Ausnahmebedingung (ERROR_THREAD_INVALID_ACCESS) bei einem Aufruf von einem anderen als einem Benutzerschnittstellenthread auszugeben. Die Zwischenablageservices werden üblicherweise von Eclipse-Komponenten, wie z. B. dem Texteditor, der viele Clients von dieser Änderung, die eine Unterbrechung zur Folge hat, isoliert, automatisch bereitgestellt. Ein vorhandener Code, der die Zwischenablage nicht direkt verwendet, sollte sicherstellen, dass die API-Methoden auf dem richtigen Thread aufgerufen werden, wenn erforderlich, mithilfe von Display.asyncExec oder syncExec, um die Zugriffe auf den Benutzerschnittstellenthread zu verlagern.

17. Tastenereignisse

In 3.0 berichtet SWT Tastenereignisse, bevor die Arbeit in OS ausgeführt wird. Dies ist sehr viel schneller der Fall als in Versionen vor 3.0. Diese Änderung erfolgte, um Tastenbelegungen in Eclipse zu unterstützen, bei denen das Abfangen von Tastenereignissen erforderlich ist, bevor ein Fensterobjekt die Chance hat, das Zeichen zu verarbeiten. Die Folgen dieser Änderung sind in dem Code sichtbar, der org.eclipse.swt.SWT.KeyDown-Ereignisse der unteren Ebene direkt verarbeitet. Dies bedeutet beispielsweise, dass, wenn eine Listenerfunktion auf einem Textfensterobjekt ein Tastenereignis empfängt, der Inhalt des Fensterobjekts (getText()) die gerade angetippte Taste nicht berücksichtigt (dies wäre in Versionen vor 3.0 der Fall gewesen). Die empfohlene Art, um den gesamten Text eines Fensterobjekts zu erhalten, einschließlich der aktuellen Taste, besteht darin, die SWT.Modify oder SWT.Verify-Ereignisse der höheren Ebene und nicht das SWT.KeyDown-Ereignis der unteren Ebene zu bearbeiten; Codes, die bereits auf diese Weise verfahren, sind von dieser Änderung nicht betroffen.

18. Tabulatorverwendung von Steuerelementen

In Versionen vor 3.0, bei denen der Schwerpunkt auf die SWT-Klasse org.eclipse.swt.widgets.Canvas oder eine ihrer Unterklassen (einschließlich angepasste Fensterobjekte) gelegen hatte, wurde mit der Eingabe von Ctrl+Tab, Shift+Tab, Ctrl+PgUp oder Ctrl+PgDn automatisch die Verwendung des nächsten/vorherigen Fensterobjekts ausgelöst, ohne dass ein Tastenereignis berichtet wurde. Das Verhalten war nicht spezifiziert und läuft der Regel zuwider, dass Canvases jede Taste sehen, die eingegeben wird. Die richtige Art, die Traversierung zu bearbeiten, besteht in der Registrierung einer Traversierungs-Listenerfunktion. Damit Eclipse 3.0 Tastenbelegungen in 3.0 richtig unterstützt, wurde das Standardverhalten geändert, sodass Canvas nun Ctrl+Tab, Shift+Tab, Ctrl+PgUp und Ctrl+PgDn Tastenereignisse statt Traversierung sieht. Stellen Sie sicher, dass Sie eine Traversierungs-Listenerfunktion registrieren, wenn Sie eine Roh-Canvas verwenden oder eine Unterklasse von Canvas definieren,.

19. Auswahl der Ereignisreihenfolge in der SWT-Tabelle und Strukturfensterobjekte

Die Auswahl mit der Maus von Elementen in den SWT-Klassen org.eclipse.swt.widgets.Table und Tree generiert die einheitliche Ereignisabfolge MouseDown-Auswahl-MouseUp in allen Betriebsumgebungen. Entsprechend generiert die Auswahl mit der Tastatur die Ereignisabfolge KeyDown-Selection-KeyUp einheitlich in allen Betriebsumgebungen. In Versionen vor 3.0 war die Ereignisabfolge nicht einheitlich, wobei Motif und Photon nicht mit dem Rest übereinstimmten, da das Auswahlereignis immer zuerst gemeldet wurde, d. h. Auswahl-MouseDown-MouseUp oder Auswahl-KeyDown-KeyUp. In 3.0 wurde die Ereignisabfolge von Motif und Photon geändert, sodass sie mit den Übrigen übereinstimmt. Ein vorhandener Code, der unter (Windows, GTK} und auf {Motif, Photon} korrekt funktionierte, dürfte vermutlich nicht davon betroffen sein. Es ist jedoch ratsam, den Code zu überprüfen, um sicherzustellen, dass er nicht auf einer ungültigen Ereignisabfolge basiert.

20. Neue Wertigkeit beim Status der Objekte

org.eclipse.core.runtime.IStatus hat eine neue Wertigkeitskonstante, IStatus.CANCEL, die verwendet werden kann, um einen Abbruch anzuzeigen. Anrufende Module von IStatus.getSeverity(), die auf einer Reihe von möglichen Wertigkeiten beruhen und auf IStatus.OK, INFO, WARNING und ERROR beschränkt sind, können von dieser Ergänzung betroffen sein. Anrufende Module von getSeverity sollten ihren Code aktualisieren, um die neue Wertigkeit miteinzubeziehen.

21. Hinweise zur Änderung erstellungsbezogener Ressourcen

In Eclipse 3.0 findet die automatische Erstellung im Arbeitsbereich nun im Hintergrundthread statt. Dafür ist eine Änderung des API-Vertrages auf org.eclipse.core.resources.IResourceChangeEvent erforderlich. Der Vertrag von IResourceChangeEvent stellte früher die folgende Reihenfolge der Ereignisse für alle Arbeitsbereichsänderungen sicher:

  1. PRE_DELETE oder PRE_CLOSE Ereignishinweis, falls zutreffend
  2. Führen Sie die Operation aus.
  3. PRE_AUTO_BUILD Ereignishinweis
  4. Falls die automatische Erstellung eingestellt ist, führen Sie eine schrittweise Arbeitsbereichserstellung durch.
  5. POST_AUTO_BUILD Ereignishinweis
  6. POST_CHANGE Ereignishinweis

Da die automatische Erstellung nun im Hintergrund läuft, gibt es keine Zusicherung mehr über die vorübergehende Beziehung zwischen den AUTO_BUILD-Ereignissen und dem POST_CHANGE-Ereignis. In Eclipse 3.0 wurden die Schritte 3-5 der vorstehenden Struktur aus der Operation entfernt. Das sich ergebende Bild sieht wie folgt aus:

  1. PRE_DELETE oder PRE_CLOSE Ereignishinweis, falls zutreffend
  2. Führen Sie die Operation aus.
  3. POST_CHANGE Ereignishinweis

Die Plattform führt regelmäßig im Hintergrund eine Erstellungsoperation des Arbeitsbereichs durch. Beachten Sie, dass dies unabhängig davon ist, ob die automatische Erstellung ein- oder abgestellt ist. Das genaue Timing, wann diese Erstellung stattfindet, ist nicht spezifiziert. Die Struktur der Erstellungsoperation ist wie folgt:

  1. PRE_BUILD Ereignishinweis (PRE_BUILD ist der neue Name für PRE_AUTO_BUILD).
  2. Falls die automatische Erstellung eingestellt ist, führen Sie eine schrittweise Arbeitsbereichserstellung durch.
  3. POST_BUILD Ereignishinweis (POST_BUILD ist der neue Name für POST_AUTO_BUILD).
  4. POST_CHANGE Ereignishinweis

Der Referenzpunkt für die von den Listenerfunktionen der automatischen Erstellung empfangenen Deltas wird sich von den Post-Change-Listenerfunktionen unterscheiden. Listenerfunktionen für die Erstellung empfangen Hinweise über alle Änderungen ab dem Ende der letzten Erstellungsoperation. Post-Change-Listenerfunktionen empfangen ein Delta, das alle Änderungen seit dem letzen Hinweis nach der Änderung beschreibt. Diese neue Struktur speichert drei Merkmale von Listenerfunktionen zur Ressourcenänderung, die seit Eclipse 1.0 zutreffend sind:

Es gibt jedoch einige wichtige Unterschiede bei diesem Ansatz. In Versionen vor Eclipse 3.0 wurden Listenerfunktionen zur automatischen Erstellungen immer vor POST_CHANGE-Listenerfunktionen aufgerufen. Aus diesem Grund stellte das Delta, das von den Listenerfunktionen zur automatischen Erstellung empfangen wurde, immer eine Untergruppe des Deltas dar, das von den POST_CHANGE-Listenerfunktionen empfangen wurde. Diese Beziehung ist nun im Wesentlichen umgekehrt. Die Listenerfunktionen zur automatischen Erstellung empfangen ein Delta, das eine Obergruppe aller seit dem Ende der letzten Hintergrunderstellung an POST_CHANGE-Listenerfunktionen übermittelten Deltas darstellt. Wie vorher können Listenerfunktionen zur automatischen Erstellung den Arbeitsbereich verändern, während dies bei Post-Change-Listenerfunktionen nicht der Fall ist.

AUTO_BUILD-Ereignis-Listenerfunktionen werden nach dem Abschluss einer Operation, mit der der Arbeitsbereich geändert wurde, nicht mehr benachrichtigt. Ein Clientcode, der Listenerfunktionen zur Ressourcenänderungen mit IWorkspace.addResourceChangeListener(IResourceChangeListener) registriert, wird von dieser Änderung vermutlich nicht betroffen sein, da AUTO_BUILD-Ereignisse niemals an diese Listenerfunktionen gemeldet wurden. Clients jedoch, die IWorkspace.addResourceChangeListener(IResourceChangeListener,int) verwenden und eine Ereignismaske angeben, die AUTO_BUILD-Ereignisse umfasst, werden durch diese Änderung vermutlich unterbrochen werden, wenn sie Annahmen darüber haben, wann und auf welchem Thread die Listenerfunktionen zur automatischen Erstellung ausgeführt werden. Falls eine Listenerfunktion zur automatischen Erstellung beispielsweise ein Domänenmodell aktualisiert, um Änderungen am Arbeitsbereich wiederzugeben, findet diese Aktualisierung möglicherweise nicht statt, wenn die den Arbeitbereich ändernde Operation zurückgegeben wird. Es ist zu beachten, dass nur der Code auf der Ebene der Benutzerschnittstelle auf diese Weise betroffen ist. Der Code auf der Kernebene, der über die API aufgerufen wird, kann innerhalb des Geltungsbereichs eines IWorkspaceRunnable aufgerufen werden. So kann er niemals sicher sein, wann eine Listenerfunktion zur Ressourcenänderung aufgerufen wird. Die vorgeschlagene Korrektur für diese Unterbrechung stellt die Verwendung von POST_CHANGE anstatt der Listenerfunktionen für die Erstellung dar, falls ein Hinweis erforderlich, bevor die Operation abgeschlossen wird.

22. Zwischenhinweise während Arbeitsbereichsoperationen

Es wird nicht mehr zugesichert, dass alle Ressourcenänderungen, die während des dynamischen Bereichs einesIWorkspaceRunnable stattfinden, in einem einzigen Hinweis gebündelt werden. Dieser Mechanismus wird nach wie vor für die Bündelung von Änderungen verwendet, um unnötige Erstellungen und Hinweise zu vermeiden, doch die Plattform kann nun entscheiden, ob Hinweise während der Operation erstellt werden. Dieser API-Vertragsänderung dürfte vermutlich keine Änderung sein, die zu Unterbrechungen für vorhandene Clients führt. Die Plattform kann entscheiden, IWorkspace.checkpoint regelmäßig während lange laufenden Operationen aufzurufen. Der Grund für diese Änderung liegt darin, dass es nun möglich ist, dass mehrere Threads den Arbeitsbereich gleichzeitig verändern. Wenn ein Thread die Änderung des Arbeitsbereichs abgeschlossen hat, ist ein Hinweis erforderlich, um Probleme der Reaktionsfähigkeit zu vermeiden, selbst wenn die andere Operation noch nicht abgeschlossen ist. Diese Änderung ermöglicht es Benutzern ebenfalls, mit der Arbeit an einer Reihe von Ressourcen zu beginnen, bevor die Operation abgeschlossen ist. Beispielsweise kann ein Benutzer jetzt damit beginnen, Dateien in einem Projekt zu durchsuchen, das noch geprüft wird. Die neue Methode IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) hat eine optionale Markierung, AVOID_UPDATE, deren Operationen als ein Hinweis für die Plattform verwendet werden kann, zu spezifizieren, ob regelmäßige Aktualisierungen gewünscht sind.

23. Erweiterungen von URL-Datenstromsteuerroutinen

Was ist betroffen: Plug-ins, die Erweiterungen zu dem Erweiterungspunkt org.eclipse.core.runtime.urlHandlers beitragen.

Beschreibung: Der Vertrag für den Erweiterungspunkt org.eclipse.core.runtime.urlHandlers wurde geändert, um den von OSGi bereitgestellten Service für die URL-Datenstromsteuerroutinen zu verwenden. Die OSGi-Unterstützung ist gegenüber derjenigen in Eclipse 2.1 übergeordnet und führt dynamische Steuerroutinen korrekt aus. Aufgrund von verschiedenen Konstruktionsproblemen mit dem Java-Basismechanismus für URL-Steuerroutingen müssen bei dem OSGi-Steuerroutingenservice registrierte URLStreamHandlers org.osgi.service.url.URLStreamHandlerService implementieren.

Erforderliche Aktion: Früher musste die Steuerroutinenklasse java.net.URLStreamHandler implementieren und den urlHandlers-Erweiterungspunkt erweitern. Der Erweiterungspunkt wird nicht mehr unterstützt und die Steuerroutine muss aktualisiert werden, um die Schnittstelle org.osgi.service.url.URLStreamHandlerService zu implementieren. Das OSGi-Gerüst stellt eine abstrakte Basisklasse (org.osgi.service.url.AbstractURLStreamHandlerService) bereit, die oberflächlich als Unterklassen verwendet werden kann, um diese Funktion auszufüllen.

Statt die Steuerroutine mithilfe eines Erweiterungspunkts zu registrieren, muss das Plug-in dies jetzt mit der Registrierung seiner Steuerroutine als einen Service durchführen. Zum Beispiel:

    Hashtable properties = new Hashtable(1);
    properties.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] {MyHandler.PROTOCOL});
    String serviceClass = URLStreamHandlerService.class.getName();
    context.registerService(serviceClass, new MyHandler(), properties);

24. Reihenfolge des Klassenladeprogramms

Was ist betroffen: Plug-ins, die Pakete zur Verfügung stellen, die auch von anderen Plug-ins zur Verfügung gestellt werden. Nur sehr wenige Plug-ins sind von dieser Änderung betroffen und für einige der betroffenen Plug-ins wird die Änderung sogar positiv sein (siehe unten).

Beschreibung: In Eclipse 2.x suchen die Klassenladeprogramme nach Klassen in der folgenden Reihenfolge: Beratung (1) übergeordnetes Klassenladeprogramm (in der Praxis ist dies ein Java-Boot-Klassenladeprogramm), anschließend (2) die eigenen Klassenpfadinhalte und schließlich (3) alle Vorbedingungen in der angegebenen Reihenfolge. OSGi bietet eine Optimierung dieses Modells. Nach diesem Ansatz wird das Klassenladeprogramms folgendermaßen vorgehen: Beratung (1) übergeordnetes Klassenladeprogramm (wieder in der Praxis das Java-Boot-Klassenladeprogramm), anschließend entweder (2a) eine einzige Vorbedingung, von der bekannt ist, dass sie Klassen in dem abgefragten Paket zur Verfügung stellt, oder (2b) die eigenen Klassenpfadeinträge für die gewünschte Klasse.

Das Klassenladeprogramm legt auf Grundlage seiner importierten oder erforderlichen Pakete fest, ob es selbst oder seine Vorbedingungen beraten. Diese Information wird im Fall eines traditionellen Plug-ins von dem Inhalt des Plug-ins erschlossen oder im Falle eines Plug-ins mit einem expliziten OSGi-Produktpaket direkt angegeben. In beiden Fällen ist a priori bekannt, welches Klassenladeprogramm die Klassen für welche Pakete liefert. Dies ermöglicht Leistungsverbesserungen und bietet eine Lösung für das ärgerliche Problem von mehreren Vorbedingungen, die zu denselben Klassen beitragen,

z. B. der Fall von Xerces und Xalan, die beide verschiedene Klassen von org.xml-Paketen enthalten. Nach dem ersten Ansatz würde das Xerces-Plug-in seine Kopie dieser Klassen und das Xalan-Plug-in seine jeweilige Kopie sehen. Da diese Plug-ins miteinander kommunizieren müssen, tritt ClassCastExceptions auf. Nach der zweiten Strategie trägt nur eines der beiden Plug-ins die doppelten Klassen bei und beide Plug-ins sehen dieselben Kopien.

Erforderliche Aktion: Die erforderliche Aktion hängt von den Einzelheiten des Anwendungsfalls ab. Die betroffenen Entwickler müssen ihren Klassenpfad überprüfen und mögliche Konflikte lösen.

25. Nicht eingerichtete Schutzdomäne für Klassenladeprogramm

Was ist betroffen: Plug-ins, die davon ausgehen, dass die Schutzdomäne für ihr Klassenladeprogramm stets eingerichtet ist.

Beschreibung: Bei Eclipse 2.1-Plug-ins war java.security.SecureClassloaders das Klassenladeprogramm und hatte als solches stets eine Schutzdomäne eingerichtet. In Eclipse 3.0 erweitern die Klassenladeprogramme SecureClassloader nicht und richten nur die Schutzdomäne ein, wenn Java-Sicherheit aktiviert ist (was normalerweise nicht der Fall ist).

Erforderliche Aktion: Die erforderliche Aktion hängt von dem Szenario ab, in dem das Plug-in die Schutzdomäne verwendet.

26. PluginModel-Objektumsetzung

Was ist betroffen: Plug-ins, die Objekte des Typs org.eclipse.core.runtime.IPlugin* inorg.eclipse.core.runtime.model.Plugin*Model umsetzen. Selbst wenn die Beziehung zwischen diesen Schnittstellen und Modellklassen in der Eclipse 2.1-API nicht spezifiziert ist, weisen wir explizit auf diese Änderung hin, da wir Exemplare von Plug-ins fanden, die auf dieser Beziehung in der 2.1-Implementierung basierten.

Beschreibung: Die Eclipse-API stellt eine Reihe von Schnittstellen (z. B.IPluginDescriptor) und so genannte "model" Klassen (z.B., PluginDescriptorModel) bereit, die zu Plug-ins und der Plug-in-Registrierung gehören. In der Eclipse 2.1-Implementierung implementieren die Modellklassen die entsprechenden Schnittstellen. In der neuen OSGi-basierten Laufzeit wurde die Plug-in-Registrierung erheblich überarbeitet, um eine Trennung zwischen dem Klassenladeprogramm und den Aspekten der Vorbedingung der Plug-ins, der Erweiterung und den Aspekten der Erweiterungspunkte zu ermöglichen. Daher kann die Eclipse 3.0-Laufzeit die in 2.1 vorhandene Implementierungsbeziehung nicht aufrechterhalten.

Erforderliche Aktion: Plug-ins, die auf dieser Nicht-API-Beziehung beruhen, müssen gemäß ihrem Anwendungsfall überarbeitet werden. Weitere Informationen finden Sie im Abschnitt der empfohlenen Änderungen in diesem Dokument und in der JavaDoc für die entsprechenden Klassen und Methoden.

27. Unvollständige Implementierung von ILibrary

Was ist betroffen: Plug-ins, die org.eclipse.core.runtime.ILibrary verwenden.

Beschreibung: Die neue Laufzeit unterhält die Klassenpfadeinträge in einer anderen und mit Eclipse inkompatiblen Form. Daher ist die Kompatibilitätsebene nicht in der Lage, die zugrunde liegenden OSGi-Strukturen als ILibrary-Objekte zu modellieren. Die Kompatibilitätsunterstützung der Laufzeit erstellt ILibrary-Objekte, muss jedoch, abgesehen von dem Pfad der Bibliothek, für alles Standardwerte annehmen.

Erforderliche Aktion: Benutzer von ILibrary sollten den Zugriff auf die gewünschten Header-Werte (z.B. Produktpaket-Klassenpfad) aus dem entsprechenden Produktpaket (siehe Bundle.getHeaders()) und die Verwendung der Hilfeklasse ManifestElement für die Interpretation der Einträge in Erwägung ziehen. Weitere Informationen finden Sie in der Klasse JavaDoc.

28 Ungültige Annahmen in Bezug auf die Form von URLs

Was ist betroffen: Plug-ins, die Annahmen in Bezug auf ihre Installationsstruktur, den Ort und das Layout des lokalen Datensystems haben.

Beschreibung: Methoden wie z. B. IPluginDescriptor.getInstallURL() geben URLs in einer bestimmten Form zurück. Obwohl ihre Form nicht angegeben ist, gehen verschiedene Plug-ins von Annahmen aus, die auf der aktuellen Implementierung basieren. Beispielsweise erwarten sie, eine Datei: URL zu erhalten und URL.getFile() zu verwenden, und verwenden möglicherweise java.io.File-Bearbeitung für das Ergebnis. Bis jetzt stellte dies einen praktikablen, jedoch instabilen Ansatz dar. Falle ein Plug-in beispielsweise auf einem Webserver installiert ist, ist es möglich, dass eine http:-URL zurückgegeben wird. Die neue Eclipse 3.0-Laufzeit ist sogar noch flexibler und eröffnet weitere Möglichkeiten für Ausführungskonfigurationen (z. B. die Verwaltung ganzer Plug-ins in JARs statt aufgeteilt in Verzeichnissen). Während die neue OSGi-basierte Laufzeit die 2.1-API nicht tatsächlich unterbricht, treten mehr Fälle auf, in denen Annahmen aktueller Plug-ins ungültig sind.

Erforderliche Aktion: Plug-in-Autoren sollten sicherstellen, dass die Informationen, auf die sie Zugriff haben müssen, über getResource() verfügbar (und auf dem Klassenpfad sind), oder die entsprechende API für den Zugriff auf die Inhalte eines Plug-ins verwenden (z.B. Bundle.getEntry(String)).

29. BootLoader-Methoden versetzt/gelöscht

Was ist betroffen: Ein Nicht-Plug-in-Code, der bestimmte Methoden aus der Klasse org.eclipse.core.boot.BootLoader aufruft.

Beschreibung: Die statischen Methoden BootLoader.startup(), shutdown() und run() wurden zu org.eclipse.core.runtime.adaptor.EclipseStarter versetzt, das einen Teil des OSGi-Gerüsts bildet. Diese API ist die Schnittstelle zwischen der Haupt-() in startup.jar und der OSGi-Gerüst/Eclipse-Laufzeit. Aufgrund der Umstrukturierung der Laufzeit können diese Methoden nicht mehr im BootLoader bleiben. Die alte BootLoader-Klasse befindet sich jetzt in der Laufzeit-Kompatibilitätsebene und ist veraltet und die versetzten Methoden haben keine Funktion.

Es gibt keinen Ersatz für die alte BootLoader.getRunnable(), da die Laufzeit die Übernahme einzelner Anwendungen nicht mehr unterstützen kann. Stattdessen müssen die Benutzer die entsprechende Anwendung beim Starten der Plattform angeben.

Erforderliche Aktion: Im Allgemeinen wird diese API von sehr wenigen Personen verwendet (sie kann nicht innerhalb eines Eclipse-Plug-ins verwendet werden). In dem seltenen Fall, dass sie verwendet wird, muss der Code angepasst werden, um die entsprechenden Methoden auf EclipseStarter zu verwenden.

30. Plug-in-Export umfasst nicht automatisch die JAR-Plug-ins

Was ist betroffen: Alle Plug-ins.

Beschreibung: In Eclipse 2.1 musste die Zeile bin.includes in build.properties eines Plug-ins keine Liste der JARs aus der Bibliotheksangabe in der Datei plugin.xml enthalten; diese JARs wurden frei hinzugefügt. In Eclipse 3.0 ist die Dateiliste im Abschnitt bin.includes von build.properties sehr umfangreich und muss alle Dateien umfassen, die Plug-in-Entwickler in ihr Plug-in bei der Erstellung oder dem Export aufnehmen möchten.

Erforderliche Aktion: Stellen Sie sicher, dass die Zeile bin.includes in der Datei build.properties alle in Ihrer Datei plugin.xml aufgeführten JARs umfasst.

31. Laufzeit-API reexportieren

Was ist betroffen: Plug-ins, die APIs offenlegen, die Elemente geänderter Laufzeit-APIs umfassen.

Beschreibung: Verschiedene Plug-ins legen APIs offen, die Elemente der Laufzeit-API umfassen. Mit den hier erläuterten Änderungen der Eclipse 3.0-Laufzeit müssen Client-Plug-ins die Verwendung der Laufzeit-API in ihrer API neu bewerten.

Erforderliche Aktion: Dieses Szenario kommt relativ selten vor, da sich die Eclipse Laufzeit-API nur wenig ändert. Abhängig vom Szenario müssen die Clients möglicherweise ihre API ändern oder sich weiterhin auf die Kompatibilitätsebene stützen.

32. Parsing-Methoden des Plug-ins auf der Plattform

Was ist betroffen: Plug-ins, die org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) verwenden.

Beschreibung: Die Methode org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) wurde versetzt. Die mit dem Factory-Argument verbundene API wurde von dem Plug-in org.eclipse.core.runtime zum Plug-in org.eclipse.core.runtime.compatibility versetzt (welches vom Laufzeit-Plug-in abhängt). Daher wurde auch die Parsing-Methode versetzt.

Erforderliche Aktion: Benutzer dieser Methode sollten dieselbe Methode für die Klasse org.eclipse.core.runtime.model.PluginRegistryModel anwenden.

33. Von Fragmenten bereitgestellte Plug-in-Bibliotheken

Was ist betroffend: Plug-ins, die einen Code in ihrem Klassenpfad angeben, diesen Code jedoch nicht zur Verfügung stellen (d. h., die JAR wird von einem Fragment bereitgestellt, z. B. das org.eclipse.swt Plug-in).

Beschreibung: Die neue Laufzeit muss im Hintergrund plug.xml-Dateien in manifest.mf-Dateien umwandeln. Dies erfolgt über eine klare mechanische Konvertierung und eine Analyse der von dem Plug-in aufgeführten und bereitgestellten JARs. Falls ein Plug-in eine JAR in seinem Klassenpfad angibt, das JAR jedoch nicht bereitstellt, ist kein Code zur Analyse vorhanden und der Plug-in-Konvertierer kann keine korrekte manifest.mf generieren.

Erforderliche Aktion: Provider dieser Plug-ins müssen entweder die entsprechende JAR im Plug-in verändern oder eine META-INF/MANIFEST.MF-Datei für ihr Plug-in erstellen/verwalten. Normalerweise erfolgt dies, indem PDE für den Empfang des anfänglichen Manifests verwendet wird und anschließend dem entsprechenden Provider-Package-Header hinzugefügt wird.

34. Änderungen an Erstellungsscripts

Was ist betroffen: Scripts (z. B. Ant build.xml-Dateien), die Klassenpfade definieren, die laufzeitbezogene JARS und Klassenverzeichnisse enthalten.

Beschreibung: Die neue Laufzeit enthält eine Reihe neuer Plug-ins und JARs. Ihre Einführung war aufgrund der Umstrukturierung der Laufzeit in konfigurierbare Teile erforderlich. In den meisten Laufzeitsituationen sind diese Änderungen transparent. Falls Sie jedoch angepasste build.xml (oder ähnliche) Scripts verwenden, die derzeit den Code gegen org.eclipse.core.runtime kompilieren, müssen Sie diese aktualisieren, bevor sie korrekt funktionieren. Ein typisches Script enthält einen Klassenpfadeintrag in einem <javac>-Task, der das org.eclipse.core.runtime Plug-in wie folgt verweist:

    ../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar

Das Laufzeit-Plug-in enthält weiterhin einen Großteil des ursprünglichen Laufzeitcodes. Verschiedene Teile der Laufzeit, die nur zu Kompatibilitätszwecken vorhanden sind, sind jedoch in einem Kompatibilitäts-Plug-in enthalten (org.eclispe.core.runtime.compatibility). Ein Großteil des neuen Laufzeitcodes ist in einer Plug-in-Sammlung enthalten (org.eclipse.osgi.*).

Erforderliche Aktion: Entwickler sollten die untenstehenden Einträge nach Bedarf hinzufügen,um Kompilierungsfehler zu beheben. Während die komplette Reihe der bereitgestellten JARs untenstehend aufgeführt ist, ist für typische Anwendungsfälle nur eine Untergruppe des Klassenpfad für die Kompilierzeit erforderlich. Üblicherweise ist die Aufnahme der /bin-Verzeichnisse eine Ermessensfrage. Die Einträge werden nachstehend in logischen Gruppierungen nach dem zur Verfügung stellenden Plug-in aufgeführt:

Außerdem können in besonderen Fällen die folgenden JARs erforderlich sein:

Bei der Aktualisierung dieser Scripte sollten Sie die Gelegenheit nutzen, um Verweise auf org.eclipse.core.boot zu bereinigen (d.h. entfernen). Dieses Plug-in ist veraltet und enthält keinen Code mehr. Die Einträge können im Klassenpfad stehen bleiben, doch sie dienen keinem Zweck und sollten entfernt werden. Es sollten entfernt werden:

    ../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar

35. Änderungen an PDE-erstellter Ant-Task

Was ist betroffen: Scripts (z.B. Ant build.xml-Dateien), die die Task eclipse.buildScript verwenden.

Beschreibung: Die PDE-Erstellung führte ein neues Merkmal in die Task eclipse.buildScript ein, um die Generierung von Erstellungsscripts von Plug-ins zu kontrollieren. Dies war aufgrund der Einführung der neuen OSGi-basierten Laufzeit erforderlich.

Erforderliche Aktion: Falls Sie Eclipse 3.0 zur Erstellung eines 2.1-basierten Produkts verwenden möchten, führen Sie in eclipse.buildScript das Merkmal "buildingOSGi" ein und setzen es auf 'false'. Zum Beispiel:

<eclipse.buildScript ... buildingOSGi="false"/>

36. Änderungen an der Ant-Task eclipse.build

Was ist betroffen: Scripts (z.B. Ant build.xml-Dateien), die die Task eclipse.buildScript verwenden.

Beschreibung: Die PDE-Erstellung führte ein neues Merkmal in die Task eclipse.buildScript ein, um die Generierung von Erstellungsscripts von Plug-ins zu kontrollieren. Dies war aufgrund der Einführung der neuen OSGi-basierten Laufzeit erforderlich.

Erforderliche Aktion: Falls Sie Eclipse 3.0 zur Erstellung eines 2.1-basierten Produkts verwenden möchten, führen Sie in eclipse.buildScript das Merkmal "buildingOSGi" ein und setzen es auf 'false'. Zum Beispiel:

<eclipse.buildScript ... buildingOSGi="false"/>

37. Änderung an der Ant-Task eclipse.fetch

Was ist betroffen: Scripts (z.B. Ant build.xml-Dateien), die die Task eclipse.buildScript verwenden.

1Description: PDE Build changed the behavior of the eclipse.fetch task to ease building eclipse in an automated build style. Die Darstellung der Elemente unterstützt jetzt nur einen Eintrag gleichzeitig und der scriptName wird immer ignoriert.

Erforderliche Aktion: Falls Sie eine Liste von Einträgen in dem Tag "elements" eines Aufrufs von eclipse.fetch hatten, verteilen Sie nun diese in verschiedenen Aufrufe von eclipse.fetch. Wenn Sie die Einstellung von scriptName verwenden, beachten Sie, dass jetzt das generierte Abrufscript immer aufgerufen wird "fetch_{elementId}". Zum Beispiel:

<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>

wird zu

<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../>
<eclipse.fetch elements="feature@org.eclipse.platform" .../>

38. Ersetzen von install.ini

Die Datei install.ini ist nicht mehr enthalten. An ihrer Stelle ist nun die Datei config.ini im Konfigurationsunterverzeichnis. Produkte, die die Datei install.ini file zur Angabe eines primären Merkmals nutzten (z.B. zur Angabe von Branding-Informationen), müssen auf die Datei config.ini geändert werden. Zusätzlich zu dem neuen Dateinamen haben sich die Namen der Schlüssel geändert.

Der Wert des Schlüssels feature.default.id in 2.1 sollte als der Wert des neuen Schlüssels eclipse.product eingerichtet werden. Der Wert der eclipse.application sollte auf "org.eclipse.ui.ide.workbench" eingerichtet werden.

Schließlich war in 2.1 das Image für das Splash-Image immer splash.bmp im Verzeichnis des Branding-Plug-ins. In 3.0 wird die Position des Splash-Images explizit von dem Schlüssel osgi.splashPath in der Datei config.ini bereitgestellt.