Questa sezione descrive le modifiche necessarie se si tenta di sostituire il plugin 3.1 per adottare i meccanismi e le API 3.2.
Eclipse 3.2 fornisce una nuova infrastruttura per l'associazione delle configurazioni di avvio alle risorse. Questa associazione consente alla piattaforma di filtrare le risorse per le configurazioni di avvio e di eliminare le configurazioni associate a progetti eliminati. La finestra di avvio è stata migliorata per supportare un insieme di filtri che consentono di nascondere le configurazioni associate a progetti chiusi ed eliminati. Anche la finestra di avvio supporta il filtraggio in base agli insiemi di lavoro nella finestra del workbench attiva, che può essere selezionata anche nella finestra di avvio.
È responsabilità del client gestire l'associazione delle risorse nelle configurazioni di avvio.
L'API è stata aggiunta a ILaunchConfigurationWorkingCopy
per impostare le risorse associate ad una
configurazione ed è stata aggiunta a ILaunchConfiguration
per ottenere le risorse associate ad una configurazione. Ad esempio, durante la migrazione devono essere considerati
le schede di avvio, i collegamenti di avvio e i partecipanti al refactoring.
Anche il codice che crea o modifica le configurazioni di avvio deve aggiornare le associazioni alle risorse.
Eclipse 3.2 fornisce una nuova infrastruttura per la migrazione delle configurazioni di avvio affinché
siano compatibili con la nuova strumentazione. Ad esempio, in Eclipse 3.2, è stato aggiunto supporto per filtrare le configurazioni di avvio in base alle risorse. Le configurazioni di avvio devono essere aggiornate per fornire le associazioni alle risorse per
bilanciare la nuova funzione. Users can manually migrate launch configurations in their
workspace from the
Run/Debug > Launching > Launch Configurations
preference page, by pressing the Migrate button.
È possibile aggiungere un nuovo attributo delegato di migrazione, facoltativo al punto di estensione
launchConfigurationTypes
, indicando una classe che implementa la nuova interfaccia
ILaunchConfigurationMigrationDelegate
.
Il delegato della migrazione è responsabile di identificare i candidati per la migrazione ed eseguire la migrazione.
È stato aggiunto un nuovo attributo facoltativo al punto di estensione launchModes
che supporta l'esternalizzazione le etichette delle azioni nel menu di avvio a discesa. I client che contribuiscono alle modalità di avvio, devono indicare le proprie etichette
da utilizzare per avviare i menu a discesa, ad esempio "Esegui come". Il nuovo attributo si chiama
launchAsLabel
. La piattaforma fornisce etichette appropriate per le modalità di
avvio dell'esecuzione, del debug e dei profili. Per la compatibilità con le versioni precedenti,
quando per una modalità di avvio non viene specificato il nuovo attributo, le etichette del menu
a discesa vengono generate come prima, mediante MessageFormat con "{0} As
".
Fare riferimento al difetto correlato 105235.
ICU4J è una serie di librerie Java che forniscono un supporto completo per Unicode, per la globalizzazione software e l'internazionalizzazione. Per poter fornire questa funzione alla comunità Eclipse, ICU4J è stato aggiunto alla piattaforma creata per Eclipse 3.2. You will see it in the build as a plug-in named com.ibm.icu. La piattaforma Eclipse utilizzerà le API ICU in Eclipse 3.2.
La migrazione del codice applicativo può essere eseguita in maniera incrementale, il che significa che non è necessaria l'adozione completa della funzione ICU4J per ottenere i vantaggi dell'utilizzo di ICU4J. Fare riferimento alla pagina ICU4J sul wiki Eclipse per ulteriori informazioni su come migrare il codice per utilizzare ICU4J.
L'aggiunta del plug-in ICU4J aggiunge all'ordine 3MB di memoria. Alcune applicazioni non possono infatti implementare ICU4J se la dimensione dell'applicazione ha la precedenza rispetto all'utilizzo della funzione ICU4J. In questo caso, è disponibile un plug-in di sostituzione (com.ibm.icu.base) dalla pagina della build della piattaforma Eclipse. Scaricare il plug-in, rimuovere il plug-in com.ibm.icu e la relativa origine dalla directory /plugins, quindi rilasciare il plug-in di sostituzione. Ciò è necessario in quanto la piattaforma Eclipse ha adottato le API ICU per la versione 3.2 e pertanto la rimozione del plug-in ICU restituirà errori di compilazione nel codice della piattaforma. Il plug-in di sostituzione ha una dimensione di circa 100KB e viene richiamato semplicemente mediante l'implementazione predefinita di JDK delle classi utilizzate più di frequente e dalle API in ICU4J. Fare riferimento alla pagina ICU4J sul wiki Eclipse per ulteriori informazioni su come utilizzare il plug-in di sostituzione ICU.
Per supportare ICU4J in JFace, sono richieste delle aggiunte API in modo da impedire ogni riferimento alle classi ICU nelle API. Ciò ha richiesto l'aggiunta di:
org.eclipse.jface.viewers.ViewerComparator
, of which org.eclipse.jface.viewers.ViewerSorter
is now a subclass.org.eclipse.jface.viewers.StructuredViewer
, to support the addition of org.eclipse.jface.viewers.ViewerComparator
.La classe ViewerSorter
ha un metodo pubblico getCollator()
che restituisce java.text.Collator
. Poiché questo metodo è un'API, esso non può essere modificato in modo da utilizzare un ICU Collator. Inoltre, le classi ICU non possono far parte dell'API (firme) in quanto una dipendenza del plug-in diretta sull'ICU impedirebbe l'utilizzo di JFace come aiutonomo (con SWT). Per risolvere queste limitazioni, è stata aggiunta la classe ViewerComparator
che utilizza un java.util.Comparator
piuttosto che un ICU Collator. Ciò è stato effettuato in quanto la classe Collator dell'ICU implementa java.util.Comparator
, pertanto qualsiasi StructuredViewer
può utilizzare il Collator piuttosto che java.text.Collator
, ma JFace non deve aggiungere una dipendenza sul plug-in ICU4J.
I due nuovi metodi aggiunti a StructuredViewer
supportano l'utilizzo del Collator dell'ICU per ordinare il contenuto del visualizzatore mediante un ViewerComparator
e non con ViewerSorter
. È preferibile che qualsiasi StructuredViewer
utilizzi questi metodi per richiamare e impostare il programma di ordinamento del visualizzatore (comparatore) al posto dei metodi getSorter()
e setSorter(ViewerSorter)
.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
The org.eclipse.equinox.common bundle includes several new API classes (e.g., Assert
and
ListenerList
) that have common names. If your code has a class with the same name and uses import *
statements to import both the local class and classes from the runtime, you might get the following error message:
The type ABC is ambiguous
Organizing the imports and choosing the appropriate import source should resolve this problem.
As a result of the code being moved into new runtime plug-ins, custom scripts that explicitly references org.eclispe.core.runtime might need to add one or more of the following plug-ins: