In diesem Abschnitt werden die Änderungen beschrieben, die erforderlich sind, wenn Sie versuchen, Ihre 2.1-Plug-ins für die Übernahme von 3.0-Mechanismen und -APIs zu verändern.
Die Eclipse 3.0-Laufzeit ist erheblich anders. Die zugrunde liegende Implementierung basiert auf der OSGi-Gerüstspezifikation. Die Eclipse 3.0-Laufzeit umfasst eine Kompatibilitätsebene (im Plug-in org.eclipse.core.runtime.compatibility), die die 2.1-APIs verwaltet. Plug-in-Entwickler, die an einer zusätzlichen Leistung und Funktion interessiert sind, sollten die Übernahme der 3.0-APIs und das Entfernen ihrer Abhängigkeit von der Kompatibilitätsebene in Erwägung ziehen. Der Kompatibilitätscode weist drei Positionen auf:
Der nachstehende Text enthält detaillierte Informationen darüber, welche Klassen und Methoden für Kompatibilitätszwecke vorhanden sind, sowie Hinweise zur Aktualisierung eines Plug-ins.
Die Eclipse-Laufzeit wurde in zwei Teile aufgeteilt; die Klassenladefunktion und das Vorbedingungsmanagement sowie das Erweiterungs-/Erweiterungspunktmanagement. Diese Aufteilung ermöglicht eine natürliche/reibungslose Übernahme der OSGi-Gerüstspezifikation für die Klassenladefunktion und das Vorbedingungsmanagement. Dadurch wiederum wird eine Reihe von neuen Funktionalitäten aus dem dynamischen Plug-in installieren/aktualisieren/deinstallieren und eine bessere Konfigurierbarkeit ermöglicht.
Während wir weiterhin von Plug-ins sprechen, ist in der neuen Laufzeit ein Plug-in in Wirklichkeit ein Produktpaket zuzüglich einiger Erweiterungen und Erweiterungspunkte. Der Begriff Produktpaket ist nach der OSGi-Gerüstspezifikation definiert und bezieht sich auf eine Sammlung von Typen und Ressourcen; ferner steht er mit produktpaketübergreifenden Vorbedingungsinformationen in Zusammenhang. Die Erweiterungsregistrierung ist die neue Form der Plug-in-Registrierung und enthält auschließlich detaillierte Angaben zu Erweiterungen und Erweiterungspunkten. Im Großen und Ganzen besteht kein erheblicher Unterschied zwischen der Erweiterungsregistrierungs-API und der entsprechenden Plug-In-Registrierungs-API (weitere Informationen finden Sie unter Registrierungen).
In der Eclipse 2.x-Laufzeit hat das Plug-in-Objekt zahlreiche Funktionen und Verantwortlichkeiten:
In der Eclipse 3.0-Laufzeit sind diese Funktionen und Verantwortlichkeiten auf verschiedene Objekte aufgeteilt.
Das Plug-in implementiert auch BundleActivator. Damit wird berücksichtigt, dass mit einem zentralen Objekt, das die Gültigkeitsdauer und Semantik eines Plug-ins darstellt, Vorgänge vereinfacht werden. Beachten Sie, dass damit jedoch nicht der schnellen Initialisierung von Datenstrukturen, die bei den Plug-ins heute üblich ist, zugestimmt wird. Wir können nicht genug betonen, dass Plug-ins aktiviert werden können, weil auf eine etwas periphere Klasse während der Prüfung einer Klasse in einem anderen Plug-in verwiesen wurde, d. h. die Tatsache, dass Ihr Plug-in aktiviert wird, bedeutet nicht, dass seine Funktion unbedingt benötigt wird. Beachten Sie, dass Sie eine andere BundleActivator-Klasse definieren können oder überhaupt keine Aktivierungsfunktion für das Produktpaket haben müssen.
Die für das Portieren einer 2.x Plug-in-Klasse zu Eclipse 3.0 erforderlichen Schritte hängen davon ab, welche Funktionen die Klasse ausübt. Wie vorstehend erläutert, fällt die meiste Gültigkeitsdauerarbeit für das Starten in einer der folgenden Kategorien an:
In der neuen Laufzeit besteht eine Trennung zwischen der Information und den Strukturen, die für die Ausführung eines Plug-ins und die entsprechenden Erweiterungen und Erweiterungspunkte erforderlich sind. Der erste Punkt wird von der OSGi-Gerüstspezifikation definiert und verwaltet. Der zweite Punkt sind Eclipse-spezifische Konzepte und sie werden von dem Eclipse-Laufzeitcode hinzugefügt. Entsprechend wurde die ursprüngliche Plug-in-Registrierung und die entsprechenden Objekte in OSGi-Produktpakete und die Eclipse Erweiterungsregistrierung aufgeteilt.
Die Teile von IPluginRegistry, die mit der Erweiterungsspezifikation zusammenhängen (z.B. IPluginDescriptor, ILibrary, IPrequisite), sind veraltet und die übrigen Teile, die zu den Erweiterungen und Erweiterungspunkten gehören, wurden nach IExtensionRegistry versetzt. Ferner sind die so genannten Modellobjekte, die zu der Plug-in-Registrierung insgesamt gehören, jetzt veraltet. Diese Typen wurden von der Laufzeit hauptsächlich zur Unterstützung von Tools wie PDE dargestellt und als Exemplar erstellt. Leider war es oft der Fall, dass die benötigten Informationen die Funktionalität oder Kapazitäten der Laufzeit überstiegen (z. B. Erinnerungszeilennummern für plugin.xml-Elemente), und schließlich mussten die potenziellen Nutzer der Laufzeitinformationen ohnehin ihre eigenen Strukturen verwalten.
Für die neue Laufzeit haben wir die von der Laufzeit bereitgestellten Funktionen neu bewertet. Sie enthält jetzt nur noch die Funktionen, die für die Ausführung der Laufzeit wesentlich sind oder deren Ausführung anderweitig äußerst schwierig ist. Wie vorstehend erwähnt, sind die Modellobjekte der Plug-in-Registrierung sowie die Plug-in-Parsing-API jetzt veraltet. Die neue Erweiterungsregistrierung verwaltet die wesentlichen erweiterungsbezogenen Informationen. Eine neue Status-Struktur (siehe org.eclipse.osgi.service.resolver.State und Entsprechendes) ermöglicht die Bearbeitung der wesentlichen, ausführungsbezogenen Informationen.
In Eclipse 3.0 wurde die NL-Fragmentstruktur aktualisiert, um eine größere Konsistenz zu erreichen. Vorher wurde davon ausgegangen, dass die Konvertierungen für Dateien wie z. B. plugin.properties sich innerhalb der von den Fragmenten bereitgestellten JARs befinden. Da sich die ursprünglichen Dateien im Stamm des entsprechenden Host-Plug-ins befinden, würde eine Position der konvertierten Dateien im Stamm der NL-Fragemente eine konsistentere Position darstellen. Zum Beispiel:
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar
Beachten Sie, dass die Datei nl1.jar früher die Konvertierungen für plugin.properties enthalten hätte. Diese Dateien befinden sich nun im Stamm des Fragments und die JAR enthält Konvertierungen aller konvertierbaren Ressourcen (d. h. Dateien, die über das Klassenladeprogramm geladen werden) des Host-Plug-ins.
Natürlich wird die Eclipse 2.1 NL-Fragmentstruktur weiterhin für ein 2.1-Host-Plug-in, das auf Eclipse 3.0 läuft, unterstützt. Sie können jedoch ein 2.1-NL-Fragment nicht in einem 3.0-Plug-in verwenden. Das Fragment muss für die neue Struktur aktualisiert werden.
Das gesamte Paket org.eclipse.core.boot ist veraltet. Der BootLoader wurde mit org.eclipse.core.runtime.Platform zusammengefügt, da es nicht mehr sinnvoll ist, zwischen Boot und Laufzeit zu trennen. Beachten Sie, das das Plug-in org.eclipse.core.boot in Wirklichkeit unterbrochen wurde und der gesamte Code entweder in die neue Laufzeit oder die Kompatibilitätsebene versetzt wurde.
IPlatformConfiguration war immer ein Typ, der von und für die Eclipse-Komponente Installieren/Aktualisieren definiert wurde. Mit der Umstrukturierung der Laufzeit können wir diesen Typ wieder an seine angemessene Position versetzen. Diese Klasse bleibt im Wesentlichen unverändert und wurde als org.eclipse.update.configurator.IPlatformConfiguration wieder verpackt.
IPlatformRunnable wurde nach rg.eclipse.core.runtime.IPlatformRunnable versetzt.
Die Methode getDeclaringPlugin()
(für beide Klassen) übergibt dem Plug-in eine Aufwärtsverbindung, die die Erweiterung bzw. den Erweiterungspunkt angibt.
Das neue Registrierungsmodell trennt die Ausführungsaspekte des Plug-ins von den Aspekten der Erweiterung/Erweiterungspunkte und enthält nicht mehr IPluginDescriptors.
Benutzer dieser API sollten die neue Methode getParentIdentifier(), die für IExtension und IExtensionPoint angegeben ist, in Erwägung ziehen.
In der ursprünglichen Laufzeit verwaltete die Plug-in-Registrierung die gesamte Laufzeitkonfiguration. In Eclipse 3.0 ist dies nun zwischen dem OSGi-Gerüst und der Erweiterungsregistrierung aufgeteilt. Daher sind diese Klassen nun veraltet. Die Hinweise zur Veraltung enthalten genaue Angaben darüber, wie der Code aktualisiert werden sollte.
In der neuen Laufzeit werden Plug-in-Objekte nicht mehr von der Laufzeit verwaltet und somit kann nicht mehr generisch über die Plattform auf sie zugegriffen werden. Entsprechend ist auch die Plug-in-Registrierung nicht mehr vorhanden bzw. ermöglicht keinen Zugriff mehr auf Plug-in-Deskriptoren. Es stehen jedoch geeignete Ersatzmethoden zur Verfügung und werden in der Javadoc der veralteten Methoden in diesen Klassen genau erläutert.
Alle Typen in diesem Paket sind nun veraltet. Weitere Informationen finden Sie in der Erläuterung über Registrierungen.
Für Clients der IWorkspace.run(IWorkspaceRunnable,IProgressMonitor)-Methode sollte die Verwendung dieser Methode überdacht und die Verwendung der ausgefeilten Methode IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor) in Erwägung gezogen werden. Die alte IWorkspace.run-Methode ermöglicht für die Dauer der IWorkspaceRunnable einen Blick auf den gesamten Arbeitsbereich. Dies bedeutet, dass eine mit dieser Methode ausgeführte Operation niemals gleichzeitig mit anderen Operationen ausgeführt werden, kann, die den Arbeitsbereich verändern. In Eclipse 3.0 wurden viele lang andauernde Operationen in die Hintergrundthreads versetzt, sodass die Wahrscheinlichkeit von Konflikten zwischen Operationen stark gestiegen ist. Falls eine modale Vordergrundoperation durch eine lang andauernde Hintergrundoperation blockiert wird, wird die Benutzerschnittstelle blockiert, bis die Hintergrundoperation abgeschlossen ist oder eine der beiden Operationen abgebrochen wird.
Es wird empfohlen, alle Verweise auf die alte IWorkspace.run auf die Verwendung der neuen Methode mit einem Regelparameter zur Zeitplanung umzustellen. Die Regel zur Zeitplanung sollte so ausgeklügelt sein, dass sie alle Änderungen durch diese Operation umfasst. Falls die Operation versucht, Ressourcen außerhalb des Geltungsbereichs der Regel der Zeitplanung zu verändern, tritt eine Laufzeitausnahmebedingung auf. Die genaue Regel zur Zeitplanung, die für eine bestimmte Operation des Arbeitsbereichs erforderlich ist, ist nicht angegeben und kann unterschiedlich sein, je nach installiertem Repository-Provider für ein bestimmtes Projekt. Das Factory
IResourceRuleFactory
sollte verwendet werden, um die Regel zur Zeitplanung für eine ressourcenverändernde Operation zu erhalten. Falls gewünscht, kann eine MultiRule zur Angabe mehrerer Ressourcenregeln verwendet werden. Die Komfortmethode MultiRule.combine kann verwendet werden, um die Regeln verschiedener ressourcenverändernder Operationen zu kombinieren.
Falls keine Sperrung erforderlich ist, kann eine Regel zu Zeitplanung von Null verwendet werden. Dies ermöglicht der Ausführungsklasse, alle Ressourcen des Arbeitsbereichs zu verändern, verhindert jedoch, dass andere Threads den Arbeitsbereich gleichzeitig verändern. Bei einfachen Änderungen des Arbeitsbereichs stellt dies die einfachste und häufigste Lösung dar.
filteredSelection
aus der Auswahl
hinzugefügt werden:
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
if (selection.isEmpty()) { IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); if (window != null) { IWorkbenchPart part = window.getPartService().getActivePart(); if (part instanceof IEditorPart) { IEditorInput input = ((IEditorPart) part).getEditorInput(); if (input instanceof IFileEditorInput) { selection = new StructuredSelection(((IFileEditorInput) input).getFile()); } } } }
IActionBars actionBars= getActionBars(); if (actionBars != null) { actionBars.setGlobalActionHandler(IDEActionFactory.ADD_TASK.getId(), getAction(textEditor, IDEActionFactory.ADD_TASK.getId())); actionBars.setGlobalActionHandler(IDEActionFactory.BOOKMARK.getId(), getAction(textEditor, IDEActionFactory.BOOKMARK.getId())); }
Es ist nun das explizite Konzept von Anmerkungstypen vorhanden, siehe Annotation.getType() und Annotation.setType(). Der Typ einer Anmerkung kann sich während seiner Gültigkeitsdauer ändern. Für die Deklaration von Anmerkungstypen wurde ein neuer Erweiterungspunkt hinzugefügt: "org.eclipse.ui.editors.annotationTypes". Ein Erweiterungstyp hat einen Namen und kann als Subtyp eines anderen deklarierten Anmerkungstyps deklariert werden. Bei der Deklaration eines Anmerkungstyps können auch die Attribute "markerType" und "markerSeverity" verwendet werden, um anzugeben, dass die Markierungen eines bestimmten Typs und einer bestimmten Wertigkeit in den Texteditoren als Anmerkungen eines bestimmten Anmerkungstypen dargestellt werden sollen. Die Attribute "markerType" und "markerSeverity" in "org.eclipse.ui.editors.markerAnnotationSpecification" sollten nicht mehr verwendet werden. Die Spezifikationen für Markierungsanmerkungen sind daher unabhängig von den Markierungen und der Name ist folglich irreführend. Der Name wird jedoch beibehalten, um die Abwärtskompatibilität sicherzustellen.
Exemplare von Unterklassen von AbstractMarkerAnnotationModel stellen die korrekten Anmerkungstypen für Anmerkungen, die sie von Markierungen erstellen, automatisch fest und richten sie ein. Um den Anmerkungstyp zu einer bestimmten Markierung oder einem Paar von markerType und markerSeverity über das Programm abzurufen, verwenden Sie org.eclipse.ui.texteditor.AnnotationTypeLookup.
Der Zugang zu den Anmerkungstypen wird von IAnnotationAccessExtension bereitgestellt. Für einen bestimmten Anmerkungstpy können Sie die Kette der Supertypen erhalten und prüfen, ob der Anmerkungstyp ein Subtyp eines anderen Anmerkungstyps ist. DefaultMarkerAnnotationAccess implementiert diese Schnittstelle.
Der Anmerkungstyp ist der Schlüssel, mit dem die zugehörige Spezifikation für die Markierungsanmerkung gefunden wird. Da Anmerkungstypen erweitert werden können, besteht auch zwischen den Spezifikationen für Markierungsanmerkungen eine implizite Beziehung. Daher wird eine Spezifikation für eine Markierungsanmerkung für einen bestimmten Anmerkungstyp durch die Spezifikationen für die Markierungsanmerkung für den Supertypen des bestimmten Anmerkungstypen abgeschlossen. Aus diesem Grund müssen Spezifikationen für Markierungsanmerkungen nicht mehr abgeschlossen werden, wie dies vorher erforderlich war. Die Spezifikationen für Markierungsanmerkungen werden von AnnotationPreferences abgerufen. Mit org.eclipse.ui.texteditor.AnnotationPreferenceLookup können Sie Spezifikationen für Markierungsanmerkungen für einen bestimmten Anmerkungstypen abrufen, der transparent den Abschluss der Benutzervorgabe gemäß der Anmerkungskette des Supertypen durchführt.
Die Spezifikation für Markierungsanmerkungen wurde durch drei zusätzliche Attribute erweitert, um die Definition von angepassten Darstellungen eines bestimmten Anmerkungstypen in der vertikalen Skala zu ermöglichen. Diese Attribute sind: "icon", "symbolicIcon" und "annotationImageProvider". Der Wert für "icon" ist der Pfad zu einer Datei, die die Abbildung des Symbols enthält. Der Wert von "symbolicIcon" kann "Fehler", "Warnung", "Info", "Task" oder "Lesezeichen" sein. Das Attribut "symbolicIcon" wird verwendet, um der Plattform mitzuteilen, dass die Anmerkung mit denselben Abbildungen dargestellt werden sollte, die von der Plattform für die Darstellung von Fehlern, Warnungen, Infos, Tasks bzw. Lesezeichen verwendet wird. Der Wert von "annotationImageProvider" ist eine Klasse, die org.eclipse.ui.texteditor.IAnnotationImageProvider implementiert, sodass eine vollständig angepasste Darstellung der Anmerkung möglich ist.
Die vertikale Skala verwendet ihre zugehörigen IAnnotationAccess/IAnnotationAccessExtension, um die Anmerkungen darzustellen. Die vertikale Skala ruft nicht mehr Annotation.paint auf. Im Allgemeinen wird nicht mehr davon ausgegangen, dass sich Anmerkungen selbst darstellen. Die Methoden "paint" und "getLayer" sind veraltet, um die Anmerkung endlich unabhängig von der Benutzerschnittstelle zu machen. DefaultMarkerAnnotationAccess dient als Standardimplementierung von IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementiert die folgende Strategie für das Ausfüllen von Anmerkungen: Falls eine Anmerkung IAnnotationPresentation implementiert, wird IAnnotationPresentation.paint aufgerufen. Falls nicht, wird der Image-Provider für Anmerkungen in den Benutzervorgaben für Anmerkungen nachgesehen. Der Image-Provider für Anmerkungen ist nur verfügbar, wenn er angegeben ist und wenn das Plug-in, das die umschließende Spezifikation für die Markierungsanmerkung definiert, bereits geladen wurde. Falls kein Image-Provider für Anmerkungen vorhanden ist, wird der Aufruf weitergeleitet. Ansonsten wird das angegebene "Symbol" nachgesehen. "symbolicIcon" wird für das letzte Zurücksetzen verwendet. Für die Darstellung von Anmerkungen ist die Anmerkungsdarstellungschicht relevant. DefaultMarkerAnnotationAccess sucht nach der Darstellungsschicht mithilfe der folgenden Strategie: Falls die Benutzervorgabe für die Anmerkung eine Darstellungsschicht angibt, wird die angegebene Schicht verwendet. Falls keine Schicht vorhanden ist und die Anmerkung IAnnotationPresentation implementiert und IAnnotationPresentation.getLayer anderweitig verwendet wird, wird die Standarddarstellungsschicht (die 0 ist) zurückgegeben.
Die folgenden Anmerkungstypen werden von dem Plug-in org.eclipse.ui.editors deklariert:
<extension point="org.eclipse.ui.editors.annotationTypes"> <type name="org.eclipse.ui.workbench.texteditor.error" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="2"> </type> <type name="org.eclipse.ui.workbench.texteditor.warning" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="1"> </type> <type name="org.eclipse.ui.workbench.texteditor.info" markerType="org.eclipse.core.resources.problemmarker" markerSeverity="0"> </type> <type name="org.eclipse.ui.workbench.texteditor.task" markerType="org.eclipse.core.resources.taskmarker"> </type> <type name="org.eclipse.ui.workbench.texteditor.bookmark" markerType="org.eclipse.core.resources.bookmark"> </type> </extension>
Die definierte markerAnnotationSpecification-Erweiterung stellt nicht mehr die Attribute "markerType" und "markerSeverity" bereit. Diese definieren das Attribut "symbolicIcon" mit dem entsprechenden Wert. Deshalb werden MarkerAnnotation.paint und MarkerAnnotation.getLayer nicht mehr aufgerufen, d. h. das Überschreiben dieser Methoden hat keine Auswirkungen. Die betroffenen Clients sollten IAnnotationPresentation implementieren.
Mit der Einführung von erweiterbaren Startmodi in 3.0 kann mehr als ein Startstellvertreter für einen Startkonfigurationstyp vorhanden sein. Versionen vor 3.0 unterstützten nur einen Startstellvertreter je Startkonfigurationstyp. Die Methode ILaunchConfigurationType.getDelegate()
ist jetzt veraltet. Die Methode getDelegate(String mode)
sollte an ihrer Stelle verwendet werden, um den Startstellvertreter für einen bestimmten Startmodus abzurufen.
Die veraltete Methode wurde so geändert, dass der Startstellvertreter für den Ausführungs
modus zurückgegeben wird.
Startregisterkartengruppen und Startregisterkarten werden nicht mehr benachrichtigt, wenn ein Startvorgang abgeschlossen ist. Die Methode launched(ILaunch)
in den Schnittstellen ILaunchConfigurationTab
und ILaunchConfigurationTabGroup
ist veraltet und wird nicht mehr aufgerufen. Wenn sich die Startfunktion auf diese Methode gestützt hat, war dies immer problematisch, da Registerkarten nur vorhanden sind, wenn der Startvorgang von dem Startdialog ausgeführt wird. Mit der Einführung des Startvorgangs im Hintergrund wird diese Methode nicht mehr aufgerufen, da der Startdialog geschlossen wird, bevor das resultierende Startobjekt vorhanden ist.
Es wurden zwei Methoden zu der Schnittstelle ILaunchConfigurationTab
hinzugefügt - aktiviert und deaktiviert. Diese neuen Methoden für die Gültigkeitsdauer werden aufgerufen, wenn eine Registerkarte geöffnet bzw. verlassen wird. Vorhandene Implementierungen von ILaunchConfigurationTab
, mit denen die von dem Debug-Plug-in (AbstractLaunchConfigurationTab
) bereitgestellte abstrakte Klasse in Unterklassen aufgeteilt werden, sind binär kompatibel, da die Methoden in der abstrakten Klasse implementiert werden.
In früheren Versionen wurde einer Registerkarte die Mitteilung initializeFrom
, wenn sie aktiviert war, und performApply
, wenn sie deaktiviert war, gesendet. Auf diese Weise stellte das Registerkartengerüst der Startkonfiguration eine registerkartenübergreifende Kommunikation über eine Startkonfiguration her (durch das Aktualisieren der Konfiguration mit den aktuellen Attributwerten, wenn eine Registerkarte verlassen wurde, und die Aktualisierung der neu geöffneten Registerkarte). Da jedoch viele Registerkarten keine registerkartenübergreifende Kommunikation durchführen, kann dies unzureichend sein. Außerdem gibt es keine Möglichkeit, zwischen einer aktivierten Registerkarte und einer Registerkarte, die eine ausgewählte Startkonfiguration zum ersten Mal anzeigt, zu unterscheiden. Die neu hinzugefügten Methoden ermöglichen es Registerkarten, zwischen Aktivierung und Initialisierung und zwischen Deaktivierung und Speichern aktueller Werte zu unterscheiden.
Die von der abstrakten Registerkarte bereitgestellte Standardimplementierung von aktiviert
ruft initializeFrom
auf. Und die Standardimplementierung von deaktiviert
ruft performApply
auf. Registerkarten, für die die Vorteile der neuen API genutzt werden sollen, sollten diese Methoden, wenn erforderlich, überschreiben.
Im Allgemeinen stellt die empfohlene Strategie für Registerkarten, die keine registerkartenübergreifende Kommunikation durchführen, die erneute Implementierung dieser Methoden, sodass sie nichts ausführen, dar.
In früheren Versionen wurde das Wechseln der Perspektive in der Startkonfiguration über die Startkonfigurationsattribute ATTR_TARGET_DEBUG_PERSPECTIVE
und ATTR_TARGET_RUN_PERSPECTIVE
angegeben. Mit dem Zusatz von erweiterbaren Startmodi in 3.0 ist dieser Ansatz nicht mehr ausreichend. Das Wechseln der Perspektive wird jetzt in der Startkonfigurationstypbasis für jeden von einem Startkonfigurationstyp unterstützten Startmodus angegeben. Es wurde zu DebugUITools
eine API hinzugefügt, um die einem Startkonfigurationstyp zugeordnete Perspektive für einen besonderen Startmodus einzurichten und zu nutzen.
Ein zusätzliches, optionales launchMode
-Element wurde zu dem Erweiterungspunkt launchConfigurationTabGroup
hinzugefügt, wodurch es einer bereitgestellten Registerkartengruppe möglich ist, die Standardperspektive für einen Startkonfigurationstyp und -modus anzugeben.
Von der Eclipse-Benutzerschnittstelle können die Benutzer die einem Startkonfigurationstyp zugeordnete Perspektive bearbeiten, indem der Startkonfigurationsdialog geöffnet und ein Startkonfigurationstypknoten in der Struktur (und nicht eine einzelne Konfiguration) ausgewählt wird. Eine Registerkarte wird angezeigt, die es dem Benutzer ermöglicht, eine Perspektive mit dem jeweiligen unterstützten Startmodus einzurichten.
Der Klasse VMRunnerConfiguration
wurden zwei Methoden hinzugefügt, um das Einrichten und Abrufen von Umgebungsvariablen zu unterstützen. Implementierungselemente von IVMRunner
sollten VMRunnerConfiguration.getEnvironment()
aufrufen und die Umgebung an die ausgeführte JVM weitergeben. Clients, die DebugPlugin.exec(String[]
cmdLine, File workingDirectory)
verwenden, können dies ausführen, indem sie DebugPlugin.exec(String[]
cmdLine, File workingDirectory, String[] envp)
aufrufen. Die einfache Weitergabe in dem Ergebnis von getEnvironment()
ist ausreichend.
In früheren Versionen hatte die VMRunnerConfiguration
ein Attribut, um den Bootpfad zu beschreiben. Das Attribut ist eine Sammlung von Zeichenfolgen
, die in dem Argument -Xbootclasspath
angegeben sind. Drei neue Attribute wurden der VMRunnerConfiguration zur Unterstützung von JVMs hinzugefügt, die das Hinzufügen an den Bootpfad ermöglichen. Die neu hinzugefügten Methoden/Attribute sind die Folgenden:
getPrependBootClassPath()
- gibt eine Sammlung von Einträgen zurück, die dem Bootpfad hinzuzufügen sind (das Argument -Xbootclasspath/p
)getMainBootClassPath()
- gibt eine Sammlung von Einträgen zurück, die auf den Bootpfad zu platziern sind (as Argument -Xbootclasspath
)getAppendBootClassPath()
- gibt eine Sammlung von Einträgen zurück, die an den Bootpfad anzuhängen sind (das Argument -Xbootclasspath/a
)Das alte Attribut getBootClassPath()
ist nach wie vor vorhanden und enthält einen komplett äquivalenten Pfad zu dem der drei neuen Attribute. VMRunners
, die die neuen Bootpfadoptionen unterstützen, sollten die neuen Attribute jedoch nutzen.
Die Arbeitskopiefunktion des Java-Modells wurde in 3.0 überarbeitet, um eine wesentlich erweiterte Funktionalität bereitzustellen. Vor 3.0 ermöglichte das Java-Modell das Erstellen von einzelnen Arbeitskopien von Kompiliereinheiten. Die Arbeitskopien können geändert und später festgeschrieben werden. Eine eingeschränkte Analyse der Arbeitskopie im Kontext des übrigen Java-Modells wurde unterstützt. Es gab jedoch keine Möglichkeit, dass diese Analysen in mehr als einer Arbeitskopie gleichzeitig berücksichtigt wurden.
Die Änderungen in 3.0 ermöglichen das Erstellen und Verwalten einer Reihe von Arbeitskopien von Kompiliereinheiten und das Durchführen von Analysen bei Vorhandensein aller Arbeitskopien einer Reihe. Beispielsweise ist es jetzt für einen Client wie die JDT-Refactoringfunktion möglich, Arbeitskopien für eine oder mehrere Kompiliereinheiten zu erstellen, deren Änderung erwogen wird, und anschließend Typverweise zwischen den Arbeitskopien aufzulösen. Früher war dies nur möglich, nachdem die Änderungen an den Arbeitskopien der Kompiliereinheit festgeschrieben worden waren.
Die Java-Modell-API wird auf zweierlei Weise verändert, um diese verbesserte Unterstützung hinzuzufügen:
(1) Die früher unter IWorkingCopy
zu findende und von ICompilationUnit
übernommene Funktionalität wurde in ICompilationUnit
zusammengefügt.
Die Schnittstelle IWorkingCopy
wurde nur an dieser Stelle genutzt und war ohne Grund allgemeiner als sie sein musste. Mit dieser Änderung wird die API vereinfacht. IWorkingCopy
ist veraltet. Andere Stellen der API, an denen IWorkingCopy
als ein Parameter oder Ergebnistyp verwendet wird, sind ebenfalls veraltet; die Ersatz-API-Methoden erwähnen ICompilationUnit
anstelle von IWorkingCopy
.
(2) Die Schnittstelle IBufferFactory
wurde durch WorkingCopyOwner
ersetzt.
Die verbesserte Unterstützung für Arbeitskopien macht erforderlich, dass ein Objekt vorhanden ist, das der Eigentümer der Arbeitskopien ist. Obwohl IBufferFactory
an der richtigen Stelle ist, vermittelt der Name nicht angemessen, wie der neue Arbeitskopiemechanismus funktioniert. WorkingCopyOwner
ist sehr viel suggestiver. Zusätzlich ist WorkingCopyOwner
als eine abstrakte Klasse und nicht als Schnittstelle deklariert, um die zukünftige Weiterentwicklung des Konzepts des Arbeitskopieeigentümers zu ermöglichen. Die einzige Methode von IBufferFactory
wird ohne Auswirkungen nach WorkingCopyOwner
versetzt. WorkingCopyOwner
implementiert nicht IBufferFactory
, um eindeutig darzustellen, dass IBufferFactory
der Vergangenheit angehört. IBufferFactory
ist veraltet. Andere Stellen der API, an denen IBufferFactory
als ein Parameter oder ein Ergebnistyp erscheint, sind ebenfalls veraltet; die Ersatz-API-Methoden erwähnen WorkingCopyOwner
anstelle von IBufferFactory
.
Diese Änderungen unterbrechen die Binärkompatibilität nicht.
Bei der Migration sollten alle Verweise auf den Typ IWorkingCopy
in Verweise auf ICompilationUnit
geändert werden. Die Implementierung von IWorkingCopy
implementiert ebenfalls ICompilationUnit
, was bedeutet, dass Objekte des Typs IWorkingCopy
sicher in ICompilationUnit
umgesetzt werden können.
Eine Klasse, die IBufferFactory
implementiert, muss durch eine Unterklasse von WorkingCopyOwner
ersetzt werden. Obwohl WorkingCopyOwner
nicht IBufferFactory
selbst implementiert, könnte die Unterklasse von WorkingCopyOwner
, die IBufferFactory
implementiert und dabei eine Brücke zwischen dem alten und neuen (IBufferFactory
erstellt als createBuffer(IOpenable)
deklariert werden, wobei WorkingCopyOwner
createBuffer(ICompilationUnit)
deklariert; ICompilationUnit
erweitert IOpenable
).
Da die Änderungen, die IWorkingCopy
und IBufferFactory
betreffen, miteinander verflochten sind, empfehlen wir die gleichzeitige Bearbeitung von beiden. Im Folgenden sind die Einzelheiten der Veraltungen dargestellt:
IWorkingCopy
(Paket org.eclipse.jdt.core
)
public void commit(Boolesch, IProgressMonitor)
ist veraltet.
ICompilationUnit
bereitgestellt:
public void commitWorkingCopy(Boolesch, IProgressMonitor)
wc.commit(b,monitor)
als ((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
um.public void destroy()
ist veraltet.
ICompilationUnit
bereitgestellt:
public void discardWorkingCopy(Boolesch, IProgressMonitor)
wc.destroy()
als ((ICompilationUnit)
wc).discardWorkingCopy()
um.public IJavaElement findSharedWorkingCopy(IBufferFactory)
ist veraltet.
ICompilationUnit
bereitgestellt:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
ersetzt IBufferFactory.
public IJavaElement getOriginal(IJavaElement)
ist veraltet.
IJavaElement
bereitgestellt:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
als elt.getPrimaryElement()
um.IWorkingCopy.getOriginal
gibt IJavaElement.getPrimaryElement
nicht Null
zurück, falls der Empfänger keine Arbeitskopie ist.public IJavaElement getOriginalElement()
ist veraltet.
ICompilationUnit
bereitgestellt:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
als ((ICompilationUnit)
wc).getPrimary()
um.IWorkingCopy.getOriginalElement
gibt IWorkingCopy.getPrimary
nicht Null
zurück, falls der Empfänger keine Arbeitskopie ist.public IJavaElement[] findElements(IJavaElement)
ist veraltet.
ICompilationUnit
deklariert.wc.findElements(elts)
als ((ICompilationUnit)
wc).findElements(elts)
um.public IType findPrimaryType()
ist veraltet.
ICompilationUnit
deklariert.wc.findPrimaryType()
als ((ICompilationUnit)
wc).findPrimaryType()
um.public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
ist veraltet.
ICompilationUnit
bereitgestellt:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
ersetzt IBufferFactory.
public IJavaElement getWorkingCopy()
ist veraltet.
ICompilationUnit
bereitgestellt:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
als ((ICompilationUnit)
wc).getWorkingCopy(null)
um.public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
ist veraltet.
ICompilationUnit
bereitgestellt:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
ersetzt IBufferFactory.
public boolean isBasedOn(IResource)
ist veraltet.
ICompilationUnit
bereitgestellt:
public boolean hasResourceChanged()
wc.isBasesOn(res)
als ((ICompilationUnit)
wc).hasResourceChanged()
um.public boolean isWorkingCopy()
ist veraltet.
ICompilationUnit
deklariert.wc.isWorkingCopy()
als ((ICompilationUnit)
wc).isWorkingCopy()
um.public IMarker[] reconcile()
ist veraltet.
ICompilationUnit
bereitgestellt:
public void reconcile(Boolesch,IProgressMonitor)
wc.reconcile()
als ((ICompilationUnit)
wc).reconcile(false, null)
um.Null
zurück; die Ersatzmethode gibt kein Ergebnis zurück.public void reconcile(boolean, IProgressMonitor)
ist veraltet.
ICompilationUnit
deklariert.wc.reconcile(b,monitor)
als ((ICompilationUnit)
wc).reconcile(b.monitor)
um.public void restore()
ist veraltet.
ICompilationUnit
deklariert.wc.restore()
als ((ICompilationUnit)
wc).restore()
um.IType
(Paketorg.eclipse.jdt.core
)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
ist veraltet.
public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
nach ICompilationUnit[]
aus.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
ist veraltet.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
nach ICompilationUnit[]
aus.IClassFile
(Paket org.eclipse.jdt.core
)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
ist veraltet.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
WorkingCopyOwner
ersetzt IBufferFactory.
JavaCore
(Paket org.eclipse.jdt.core
)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
ist veraltet.
public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
ersetzt IBufferFactory.
ICompilationUnit[]
nach IWorkingCopy[]
aus.SearchEngine
(Paket org.eclipse.jdt.core.search
)
public SearchEngine(IWorkingCopy[])
ist veraltet.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
nach ICompilationUnit[]
aus.Das Plug-in org.eclipse.help, das früher die APIs und Erweiterungspunkte für die Bereitstellung und Erweiterung des Hilfesystems sowie die Darstellung der Hilfe enthalten hat, enthält jetzt nur noch APIs und Erweiterungspunkte für die Bereitstellung und den Zugriff auf Hilferessourcen. Einen Teil der Benutzerschnittstelleimplementierung der Standardhilfe, die in diesem Plug-in enthalten war, wurde zusammen mit den APIs für die Erweiterung der Implementierung in ein neues Plug-in org.eclipse.help.base versetzt. Die APIs und der Erweiterungspunkt für die Bereitstellung der Benutzerschnittstellenhilfe sowie die Anzeige der Hilfe wurden in das Plug-in org.eclipse.ui versetzt. Diese Umstrukturierung ermöglicht Anwendungen eine größere Flexibilität im Hinblick auf das Hilfesystem; die neue Struktur ermöglicht es Anwendungen, die auf der generischen Workbench basieren, ihre eigene Hilfebenutzerschnittstelle und/oder Hilfeimplementierung bereitzustellen oder das Hilfesystem vollständig auszulassen.
Da die betroffenen Erweiterungspunkte und API-Pakete nur von dem Hilfesystem selbst genutzt werden sollten, ist es unwahrscheinlich, dass vorhandene Plug-ins von dieser Änderung betroffen sind. Sie werden hier lediglich der Vollständigkeit halber aufgenommen:
In 3.0 wurde eine neue API für die Implementierung von angepassten Suchvorgängen hinzugefügt. Die ursprüngliche API ist in 3.0 veraltet und wir empfehlen, Clients zu der neuen API in den Paketen org.eclipse.search.ui and org.eclipse.search.ui.text zu portierten.
Clients müssen Implementierungen von ISearchQuery
, ISearchResult
und ISearchResultPage
erstellen. Die ISearchResultPage
-Implementierung muss anschließend in dem neuen Erweiterungspunkt org.eclipse.search.searchResultViewPages
bereitgestellt werden.
Standardimplementierungen für ISearchResult
und ISearchResultPage
werden in dem Paket
org.eclipse.search.ui.text
bereitgestellt.
Vor 3.0 führte der Aufruf von DirectoryDialog.setMessage(String-Zeichenfolge) oder MessageBox.setMessage(String string) von SWT mit einem Wert von Null für die Zeichenfolge zu einem Dialog ohne Text im Titel. Dieses Verhalten war nicht spezifiziert (die Weitergabe von Null war nie zulässig) und führt zu Problemen mit getMessage, für das eine Rückgabe von Null nicht zulässig ist. In 3.0 führt die Weitergabe von Null jetzt zu der Ausgabe einer Ausnahmebedingung IllegalArgumentException und die Spezifikationen wurden geändert, um dies wiederzugeben, sodass die Methode mit ihrer Superklasse Dialog.setMessage in Einklang steht. Stellen Sie bei der Verwendung von Dialog.setMessage sicher, dass die weitergegebene Zeichenfolge niemals Null ist. Geben Sie einfach eine leere Zeichenfolge weiter, wenn Sie einen Dialog ohne Text im Titel möchten.
Die Unterstützung gleichzeitiger Operationen erfordert ausgereifterte Arten für das Anzeigen des modalen Fortschritts. Als Teil der Flexibilitätsbemühungen wurde eine zusätzliche Fortschrittsunterstützung in der Klasse IProgressService implementiert. Die bisherige Art zum Anzeigen des Fortschritts mit dem ProgressMonitorDialog funktioniert weiterhin. Um die Benutzererfahrung zu verbessern, empfehlen wir jedoch die Migration auf den neuen IProgressService.
Das Dokument Modalen Fortschritt in Eclipse 3.0 anzeigen enthält Informationen über die Migration auf den neuen IProgressService.
Der Erweiterungspunkt der Debug-Aktionsgruppen wurde entfernt (org.eclipse.debug.ui.debugActionGroups). In Eclipse 3.0 wurde die Unterstützung der Workbench für Aktivitäten über den Erweiterungspunkt org.eclipse.platform.ui.activities eingeführt. Diese Unterstützung stellt alles bereit, was die Debug-Aktionsgruppen bereitgestellt haben, ist einfacher zu verwenden (sie unterstützt Muster anstatt einer ausführlichen Angabe aller Aktionen) und verfügt über eine programmatische API zur Unterstützung. Wenn Verweise auf die alten Erweiterungspunkte nicht entfernt werden, führt dies zu keinen Störungen. Verweise auf den Erweiterungspunkt werden einfach ignoriert. Softwareanbieter werden dazu aufgefordert, die Workbench-Aktivitätenunterstützung zu nutzen, um sprachspezifische Debuggeraktionen sprachspezifischen Aktivitäten zuzuordnen (z. B. können C++ Debugaktionen möglicherweise einer Aktivität mit dem Namen "Developing C++" zugeordnet werden).
IBreakpointManager definiert jetzt die Methoden setEnabled(boolean) und isEnabled(). Wenn der Ünterbrechungspunktmanager deaktiviert ist, sollten Debugger alle registrierten Unterbrechungspunkte ignorieren. Die Debug-Plattform stellt auch einen neuen Mechanismus für die Listenerfunktion, IBreakpointManagerListener, zur Verfügung, der es Clients ermöglicht, sich beim Unterbrechungspunktmanager zu registrieren, um benachrichtigt zu werden, wenn sich seine Aktivierung ändert. Die Sicht 'Unterbrechungspunkte' ruft diese API von einer neuen Umschaltaktion auf, die den Benutzern die Auswahl "Alle Unterbrechungspunkte überspringen" ermöglicht. Debugger, die die Aktivierung des Unterbrechungspunktmanagers nicht berücksichtigen, werden daher als unterbrochen angezeigt, wenn der Benutzer versucht, dieses Feature zu verwenden.
Mit Java verwandte Sprachen (wie z. B. JSP, SQLJ, JWS, etc.) sollten in der Lage sein, an Java-Suchvorgängen teilzunehmen. Insbesondere sollten Implementierungselemente dieser Sprachen in der Lage sein, Folgendes auszuführen:
Ein solches Implementierungselement wird als Suchteilnehmer bezeichnet. Es erweitert die Klasse SearchParticipant. Suchteilnehmer werden an Suchabfragen übergeben (siehe SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).
Für das Indexieren oder Suchen von Übereinstimmungen muss ein Suchteilnehmer eine Unterklasse von SearchDocument definieren, die die Inhalte des Dokuments durch Überschreiben von entweder getByteContents() oder getCharContents() abrufen kann. Ein Exemplar dieser Unterklasse wird an getDocument(Zeichenfolge) zurückgegeben.
Ein Suchteilnehmer, der ein Dokument indexieren möchte, verwendet SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath), um das Indexieren eines bestimmten Dokuments in dem Index zu terminieren. Sobald das Dokument für das Indexieren bereit ist, ruft das zugrunde liegende Gerüst SearchParticipant.indexDocument(SearchDocument, IPath) auf. Der Suchteilnehmer erhält dann den Inhalt des Dokuments, wertet es aus und fügt mithilfe von SearchDocument.addIndexEntry(char[], char[]) Indexeinträge hinzu.
Nach dem Indexieren können die Indizes abgefragt und Übereinstimmungen mithilfe von SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) gefunden werden. Zunächst wird der Suchteilnehmer mithilfe von SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope) nach den für diese Abfrage benötigten Indizes gefragt. Für jeden Indexeintrag, für den eine Übereinstimmung mit dem angegebenen Muster festgestellt wird, wird durch das Abfragen des Suchteilnehmers (siehe getDocument(Zeichenfolge)) ein Suchdokument erstellt. Alle diese Dokumente werden an den Suchteilnehmer weitergegeben, sodass die Übereinstimmungen mithilfe von locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor) gefunden werden können. Der Suchteilnehmer benachrichtigt den SearchRequestor mithilfe des acceptSearchMatch(SearchMatch) über die Übereinstimmungen der Suche und die Weitergabe eines Exemplars an eine Unterklasse von SearchMatch.
Ein Suchteilnehmer kann einen Teil seiner Arbeit an den Standard-Java-Suchteilnehmer delegieren. Ein Exemplar dieses Standardteilnehmers wir mithilfe von SearchEngine.getDefaultSearchParticipant() empfangen. Wenn ein SQLJ-Teilnehmer dazu aufgefordert wird, Übereinstimmungen zu finden, kann er .java-Dokumente aus seinen .sqlj-Dokumenten erstellen und die Arbeit mit der Weitergabe der .java-Dokumente an den Standardteilnehmer delegieren.