Tento oddíl popisuje změny, které jsou nezbytné, pokud se pokoušíte změnit svůj modul plug-in pro verzi 3.1 tak, aby adoptoval mechanizmy a rozhraní API verze 3.2.
Eclipse 3.2 nabízí novou infrastrukturu pro přidružování konfigurací spuštění k prostředkům. Toto mapování umožňuje platformě provádět filtrování založené na prostředcích na konfiguracích prostředí a umožňuje platformě volitelně odstranit konfigurace spuštění, když bude odstraněn přidružený projekt. Dialogové okno spuštění bylo rozšířeno o podporu sady filtrů za účelem volitelného skrytí konfigurací asociovaných s uzavřenými a odstraněnými projekty. Dialogové okno spuštění rovněž podporuje filtrování založené na vybraných pracovních sadách v aktivním okně pracovní plochy, které lze v dialogovém okně spuštění rovněž vybrat.
Správa mapování prostředků pro konfigurace spuštění je zodpovědností klienta.
Do ILaunchConfigurationWorkingCopy
bylo přidáno rozhraní API za účelem nastavení prostředků
asociovaných s konfigurací. Do ILaunchConfiguration
bylo přidáno rozhraní API za účelem získání prostředků asociovaných s konfigurací. Při migraci byste měli zvážit například karty spuštění, zástupce pro spuštění a účastníky opětovné deklarace.
Kód, který vytváří nebo upravuje konfigurace spuštění, by měl rovněž aktualizovat mapování prostředků.
Za účelem kompatibility s novými nástroji nabízí Eclipse 3.2 novou infrastrukturu pro migraci konfigurací spuštění. Do Eclipse 3.2 byla například přidána podpora pro provádění filtrování na bázi prostředků u konfigurací spuštění. Aby bylo možné této nové funkce využít, konfigurace spuštění musí přejít na vyšší verzi, aby poskytovaly mapování prostředků. Uživatelé mohou ručně migrovat konfigurace spuštění ve svém pracovním prostoru ze stránky předvoleb
Spustit/ladit > Spouštění > Konfigurace spuštění
stisknutím tlačítka Migrovat.
Do bodu rozšíření launchConfigurationTypes
byl přidán nový volitelný atribut delegáta migrace určující třídu, která implementuje nové rozhraní ILaunchConfigurationMigrationDelegate
.
Delegát migrace je zodpovědný za identifikaci kandidátů migrace a jejich migraci.
Do bodu rozšíření launchModes
byl přidán nový volitelný atribut, který řádně podporuje externalizaci štítků akcí kaskádové nabídky spuštění. Klienti, kteří přispívají režimy spuštění, by měli uvést náležitý štítek, který se má použít pro kaskádové nabídky spuštění, jako např. "Spustit jako". Nový atribut je pojmenován launchAsLabel
. Platforma poskytuje náležité štítky pro režimy spuštění, ladění a spuštění profilu. Kvůli zpětné kompatibilitě v případě, kdy není pro režim spuštění nový atribut určen, jsou štítky kaskádové nabídky generovány jako předtím, tj. prostřednictvím MessageFormat s "{0} As
".
Viz související chyba 105235.
ICU4J je množina knihoven Java, která poskytuje komplexnější podporu pro Unicode, globalizaci a internacionalizaci softwaru. Aby byla tato funkčnost poskytnuta komunitě Eclipse, byly do sestavení platformy pro Eclipse 3.2 přidány ICU4J. V sestavení se zobrazí jako modul plug-in s názvem com.ibm.icu. V Eclipse 3.2 bude platforma Eclipse využívat rozhraní API ICU.
Migrace aplikačního kódu může být provedena přírůstkově, což znamená, že plné adoptování funkce všech ICU4J není pro využití výhod plynoucích z použití ICU4J nezbytné. Další podrobnosti o způsobu migrace kódu k použití ICU4J najdete na stránce ICU4J v Eclipse Wiki.
Přidání modulu plug-in ICU4J přidá k obsazenému prostoru 3 MB. Pokud má velikost aplikace přednost před adoptováním funkce ICU4J, některé aplikace možná nebudou chtít ICU4J absorbovat. V tom případě je na stránce sestavení platformy Eclipse k dispozici náhradní modul plug-in (com.ibm.icu.base). Stáhněte modul plug-in, odeberte modul plug-in com.ibm.icu a jeho zdrojový protějšek z adresáře /plugins a vložte náhradní modul plug-in. To je nezbytné, protože platforma Eclipse převzala ve verzi 3.2 rozhraní API ICU, takže pouhé odebrání modulu plug-in ICU by vedlo k chybám kompilace kódu platformy. Náhradní modul plug-in má velikost asi 100 kB a jednoduše průběžně volá výchozí implementaci JDK nejčastěji používaných tříd a rozhraní API v ICU4J. Další podrobnosti o použití náhradního modulu plug-in ICU si můžete znovu přečíst na stránce ICU4J v Eclipse Wiki.
Podpora ICU4J v modulu JFace vyžadovala některé kreativní dodatky rozhraní API, které zabraňovaly odkazování tříd ICU v rozhraní API. To vedlo k přidání:
org.eclipse.jface.viewers.ViewerComparator
, jíž je org.eclipse.jface.viewers.ViewerSorter
nyní podtřídou.org.eclipse.jface.viewers.StructuredViewer
za účelem podpory přidání org.eclipse.jface.viewers.ViewerComparator
.Třída ViewerSorter
má veřejnou metodu getCollator()
, která vrací java.text.Collator
. Protože tato metoda je rozhraním API, nelze ji jednoduše změnit tak, aby používala modul Collator ICU. Rovněž třídy ICU nemohou být součástí rozhraní API (signatur), protože přímá závislost modulů plug-in na ICU by zabránila samostatnému použití modulu JFace (s SWT). Aby bylo těmto omezením vyhověno, byla přidána třída ViewerComparator
, která používá java.util.Comparator
místo modulu Collator ICU. To bylo provedeno, protože třída Collator ICU implementuje java.util.Comparator
, takže libovolný StructuredViewer
nyní může používat modul Collator ICU místo java.text.Collator
, ale modul JFace nemusí přidat závislost na modulu plug-in ICU4J.
Dvě nové metody přidané do StructuredViewer
podporují použití modulu Collator ICU k řazení obsahů prohlížeče prostřednictvím ViewerComparator
místo ViewerSorter
. Doporučuje se, aby libovolný StructuredViewer
nyní používal k získání/nastavení řadiče (komparátoru) prohlížeče místo metod getSorter()
a setSorter(ViewerSorter)
tyto metody.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
Balík org.eclipse.equinox.common zahrnuje několik nových tříd API (např. Assert
a
ListenerList
) mající obecné názvy. Pokud váš kód obsahuje třídu se stejným názvem a používá k importu lokální třídy a třídy z běhové komponenty příkazy import *, můžete obdržet následující chybovou zprávu:
Typ ABC je nejednoznačný
Tento problém by mělo vyřešit uspořádání importů a výběr příslušného zdroje importu.
V důsledku přesouvání kódu do nových běhových modulů plug-in budou uživatelské skripty, které výslovně odkazovaly na org.eclispe.core.runtime, možná potřebovat přidat minimálně jeden z následujících modulů plug-in: