In diesem Abschnitt werden die Änderungen beschrieben, die erforderlich sind, wenn Sie versuchen, Ihre Plug-ins aus Version 3.1 für die Übernahme von Mechanismen und APIs aus Version 3.2 zu verändern.
Eclipse 3.2 bietet eine neue Infrastruktur für die Zuordnung von Ressourcen zu Startkonfigurationen. Durch diese Zuordnung kann die Plattform eine ressourcenbasierte Filterung bei Startkonfigurationen ausführen und optional Startkonfigurationen löschen, wenn ein zugeordnetes Projekt gelöscht wurde. Der Startdialog wurde erweitert und unterstützt nun eine Reihe von Filtern, mit denen Konfigurationen, die geschlossenen und gelöschten Projekten zugeordnet sind, optional ausgeblendet werden können. Außerdem unterstützt der Startdialog eine Filterung auf der Basis von ausgewählten Arbeitssets im aktiven Workbenchfenster, das im Startdialog ebenfalls ausgewählt werden kann.
Für die Verwaltung der Ressourcenzuordnung zu Startkonfigurationen ist der Client zuständig.
Zu ILaunchConfigurationWorkingCopy
wurde eine API hinzugefügt, um die einer Konfiguration zugeordneten Ressourcen festzulegen. In ILaunchConfiguration
wurde eine API aufgenommen, um die einer Konfiguration zugeordneten Ressourcen abzurufen. Bei der Migration sollten beispielsweise Registerkarten und Direktaufrufe für Startvorgänge ebenso berücksichtigt werden wie Teilnehmer an Refactoringoperationen.
Code, der Startkonfigurationen erstellt oder ändert, sollte ebenfalls Ressourcenzuordnungen aktualisieren.
Eclipse 3.2 bietet eine neue Infrastruktur, mit der Startkonfigurationen so migriert werden können, dass sie mit den neuen Tools kompatibel sind. Beispielsweise wurde in Eclipse 3.2 eine Unterstützung für die Ausführung von ressourcenbasierten Filtervorgängen für Startkonfigurationen hinzugefügt. Für die Startkonfigurationen ist ein Upgrade erforderlich, damit die Ressourcenzuordnungen diese neue Funktion nutzen können. Benutzer können die Migration von Startkonfigurationen in ihrem Arbeitsbereich manuell
über die Benutzervorgabenseite
Ausführen/Debug > Startvorgang > Startkonfigurationen
durch Auswahl der Schaltfläche Migrieren vornehmen.
Zum Erweiterungspunkt launchConfigurationTypes
wurde ein neues optionales Attribut für einen Migrationsstellvertreter hinzugefügt, indem eine Klasse angegeben wird, die die neue Schnittstelle ILaunchConfigurationMigrationDelegate
implementiert.
Ein Migrationsstellvertreter dient dazu, Migrationskandidaten zu ermitteln und zu migrieren.
Zum Erweiterungspunkt launchModes
wurde ein neues optionales Attribut hinzugefügt, damit die Auslagerung der Aktionsbezeichnungen in einem gestaffelten Startmenü korrekt ausgeführt wird. Clients, die Startmodusangaben ergänzen, sollten die korrekte Bezeichnung für gestaffelte Startmenüs
angeben, beispielsweise "Ausführen als". Das neue Attribut heißt launchAsLabel
. Korrekte Bezeichnungen wurden durch die Plattform für die Startmodi der Ausführung, des Debugs und der Profilermittlung bereitgestellt. Wenn das neue Attribut für einen Startmodus nicht angegeben wird, werden die Bezeichnungen für die gestaffelten Menüs aus Gründen der Abwärtskompatibilität wie zuvor generiert, als über MessageFormat mit dem Format {0} als
.
Weitere Informationen enthält der zugehörige Programmfehler 105235.
ICU4J ist eine Gruppe von Java-Bibliotheken, die eine umfassendere Unterstützung für Unicode, die Softwareglobalisierung und die Internationalisierung bereitstellt. Um diese Funktionalität für die Eclipse-Benutzergemeinschaft verfügbar zu machen, wurde ICU4J zum Plattformbuild für Eclipse 3.2 hinzugefügt. Im Build ist es als Plug-in namens com.ibm.icu erkennbar. Die Eclipse-Plattform verwendet ICU-APIs in Eclipse 3.2.
Die Migration von Anwendungscode kann schrittweise erfolgen. Dies bedeutet, dass die Übernahme der gesamten Funktionalität von ICU4J nicht erforderlich ist, um die Vorteile der Verwendung von ICU4J zu nutzen. Weitere Details zur Migration Ihres Codes für die Verwendung von ICU4J finden Sie auf der Seite ICU4J im Eclipse-Wiki.
Die Aufnahme des ICU4J-Plug-ins führt zu einer Erhöhung des Speicherbedarfs um 3 MB. Falls die Anwendungsgröße wichtiger als die Übernahme der ICU4J-Funktionalität ist, kann es sein, dass ICU4J bei manchen Anwendungen nicht verwendet werden sollte. Für solche Fälle ist das Ersatz-Plug-in com.ibm.icu.base auf der Seite mit dem Eclipse-Plattformbuild verfügbar. Laden Sie das Plug-in herunter, entfernen Sie das Plug-in com.ibm.icu und seine entsprechenden Quellendateien aus dem Verzeichnis "/plugins", und geben Sie das Ersatz-Plug-in frei. Dies ist erforderlich, weil die Eclipse-Plattform die ICU-APIs bei Version 3.2 übernommen hat. Falls Sie lediglich das ICU-Plug-in entfernen würden, entstünden hierdurch Kompilierungsfehler im Plattformcode. Das Ersatz-Plug-in ist ca. 100 KB groß und führt einfach Aufrufe über die JDK-Standardimplementierung der am meisten verwendeten Klassen und APIs in ICU4J durch. Auch zur Verwendung des ICU-Ersatz-Plug-ins finden Sie auf der Seite ICU4J im Eclipse-Wiki weitere Informationen.
Zur Unterstützung von ICU4J in JFace waren einige API-Zusätze erforderlich, um Verweise auf ICU-Klassen in der API zu verhindern. Aus diesem Grund wurde Folgendes hinzugefügt:
org.eclipse.jface.viewers.ViewerComparator
, die nun als übergeordnete Klasse für die Unterklasse org.eclipse.jface.viewers.ViewerSorter
dient.org.eclipse.jface.viewers.StructuredViewer
hinzugefügt, um das Hinzufügen von org.eclipse.jface.viewers.ViewerComparator
zu unterstützen.Die Klasse ViewerSorter
enthält eine allgemein zugängliche Methode getCollator()
, die ein Objekt java.text.Collator
zurückgibt. Da es sich bei dieser Methode um eine API handelt, konnte sie nicht einfach durch die Verwendung eines ICU-Collators ersetzt werden. Außerdem können ICU-Klassen nicht Bestandteil der API (Signaturen) sein, da eine direkte Abhängigkeit der Plug-ins von ICU eine eigenständige Verwendung von JFace (mit SWT) verhindern würde. Um diese Einschränkungen zu berücksichtigen, wurde die Klasse ViewerComparator
hinzugefügt, die anstelle eines ICU-Collators java.util.Comparator
verwendet. Dies wurde vorgenommen, weil die Collatorklasse von ICU java.util.Comparator
implementiert. Jedes beliebige Objekt StructuredViewer
kann daher nun den ICU-Collator statt java.text.Collator
verwenden, aber JFace muss keine Abhängigkeit vom ICU4J-Plug-in hinzufügen.
Die beiden neuen Methoden, die zu StructuredViewer
hinzugefügt wurden, unterstützen die Verwendung des ICU-Collators, um den Inhalt der Anzeigefunktion über ViewerComparator
anstelle von ViewerSorter
zu unterstützen. Es empfiehlt sich, dass alle Objekte des Typs StructuredViewer
jetzt diese Methoden verwenden, um die Sortierkomponente der Anzeigefunktion (Vergleichsoperator) abzurufen und festzulegen, statt die Methoden getSorter()
und setSorter(ViewerSorter)
zu verwenden.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
Das Produktpaket org.eclipse.equinox.common enthält verschiedene neue API-Klassen (z. B. Assert
und
ListenerList
), die allgemeine Namen tragen. Falls Ihr Code eine Klasse gleichen Namens enthält und Anweisungen "import *" enthält, um sowohl die lokalen Klassen als auch die Klassen aus der Laufzeit zu importieren, wird möglicherweise die folgende Fehlernachricht ausgegeben:
Der Typ ABC ist mehrdeutig (ambiguous).
Dieses Problem sollte durch die Verwaltung der Importe und die Auswahl der passenden Importquelle gelöst werden können.
Da der Code in neue Laufzeit-Plug-ins versetzt wurde, müssen angepasste Scripts, die explizit auf org.eclipse.core.runtime verweisen, möglicherweise eines oder mehrere der folgenden Plug-ins hinzufügen: