Eclipse è stato modificato tra le versioni 2.1 e 3.0 in modi incompatibili che influiscono sui plugin. Le sezioni di seguito riportate descrivono le aree modificate e forniscono istruzioni per la migrazione dei plugin dalla versione 2.1 alla versione 3.0. È opportuno fare riferimento a queste sezioni solo se si verificano problemi durante l'esecuzione del plugin 2.1 su 3.0.
L'intestazione dei file manifest per i plugin (e i frammenti dei plugin) è stata modificata per includere una nuova riga che identifica la versione manifest appropriata del plugin. Prima della versione 3.0, i plugin non presentavano nessuna riga <?eclipse ...?>, con la versione 3.0, devono sempre possedere una simile riga. Questa modifica è stata apportata per consentire al runtime di Eclipse di riconoscere i plugin precedenti alla versione 3.0 che non sono stati trasferiti alla versione 3.0, in modo da fornire automaticamente una maggiore compatibilità binaria per tali plugin. Di seguito viene riportato il formato generale del file plugin.xml (fragment.xml è simile):
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
...
</plugin>
I file manifest del plugin creati da PDE 3.0 hanno automaticamente questo formato. Si consiglia di utilizzare lo strumento di migrazione plugin di PDE. Questo strumento consente di inserire la riga indicata nel file manifest dei plugin e dei frammenti dei plugin 2.1 e trasferisce molte altre modifiche descritte in questa sezione.
Se si aggiunge questa istruzione a un file plugin.xml (manualmente o utilizzando PDE), il file deve essere anche aggiornato per visualizzare esplicitamente i plugin da cui dipende. Ad esempio, prima di Eclipse 3.0, le dipendenze su org.eclipse.core.runtime e org.eclipse.core.boot erano implicite. Con la versione 3.0, org.eclipse.core.boot non è più necessario e gli sviluppatori devono scegliere tra org.eclipse.core.runtime e org.eclipse.core.runtime.compatibility (o nessuno dei due) in base alle necessità.
Nota: questa è una delle incompatibilità che non influisce sul modo in cui i plugin binari 2.1 vengono eseguiti da Eclipse 3.0.
Il plugin org.eclipse.ui, utilizzato come plugin principale dell'UI della piattaforma, fornisce ora solo l'API e i punti di estensione per il workbench generico (ad esempio, non specifico dell'IDE). L'API e i punti di estensione facoltativi e specifici dell'IDE sono stati spostati su altri plugin.
L'impatto di questa modifica è duplice: (1) i punti di estensione org.eclipse.ui spostati presentano nuovi id, (2) l'elenco dei plugin necessari è stato modificato.
I punti di estensione org.eclipse.ui della tabella di seguito riportata sono stati spostati in altri plugin, causando la modifica degli id. Se un plugin esistente fornisce un'estensione ai punti di estensione spostati, il riferimento nell'attributo "point" dell'elemento <extension> nel file manifest del plugin deve essere modificato per fare riferimento ai nuovi id dei punti di estensione corrispondenti. Lo strumento di migrazione del plugin del PDE consente di apportare queste correzioni.
Nota: questa è una delle incompatibilità che non influisce sul modo in cui i plugin binari 2.1 vengono eseguiti da Eclipse 3.0. Il runtime di Eclipse 3.0 individua automaticamente i plugin precedenti alla versione 3.0 (dall'assenza della riga <?eclipse version="3.0"?> sopra menzionata nel file manifest del plugin) e compensa automaticamente le modifiche ai punti di estensione e alla dipendenza del plugin.
Id vecchio punto di estensione |
Id nuovo punto di estensione |
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.editors.markerAnnotationSpecification |
Nella tabella seguente vengono riportati i pacchetti API forniti in precedenza dal plugin org.eclipse.ui che sono stati spostati in altri plugin. (I nomi dei pacchetti API, delle classi, dei campi e dei metodi non sono stati modificati). In alcuni casi, i pacchetti API non vengono suddivisi tra più plugin. Poiché le classi API visibili a qualsiasi plugin sono determinate dall'elenco dei plugin necessari, queste modifiche possono richiedere la regolazione degli elementi "<requires>" nel file manifest di un plugin esistente, per riacquistare l'accesso alla classe API.
Questa modifica influisce solo sui plugin che dipendono dal plugin org.eclipse.ui (incluso <import plugin="org.eclipse.ui"/> nella sezione <requires> del file manifest del plugin); tutti gli altri plugin non risultano compromessi. Se compromesso, è possibile che sia necessario modificare l'elemento <import> o aggiungere elementi <import> supplementari, in modo che tutte le classi API necessarie al plugin si trovino nell'ambito. I plugin dovrebbero utilizzare solo le dipendenze dai plugin che effettivamente vengono utilizzati. Includere dipendenze non necessarie riduce le prestazioni di runtime, in quanto il caricatore della classe Java deve ricercare le classi in tutte le dipendenze. (Lo strumento di migrazione del plugin del PDE corregge le dipendenze e consente di determinarne un insieme minimo).
Pacchetto API |
Plugin 2.1 |
Plugin 3.0 corrispondenti |
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 |
Il runtime della piattaforma Eclipse 3.0 è basato su OSGi e necessita di modifiche alla struttura dei due plugin di runtime della piattaforma, org.eclipse.core.runtime e org.eclipse.core.boot.
Un nuovo plugin org.eclipse.core.runtime.compatibility fornisce un ponte di implementazione tra le API vecchie e nuove e rappresenta la nuova ubicazione per molte API obsolete rilevate in precedenza in org.eclipse.core.runtime e org.eclipse.core.boot. I punti di estensione del runtime della piattaforma non sono compromessi dalla ristrutturazione.
Quando si migra il plugin esistente alla versione 3.0, il file manifest del plugin deve essere aggiornato per riflettere la nuova struttura dei plugin del runtime della piattaforma Eclipse. Lo strumento di migrazione del file manifest del plugin del PDE aggiunge una dipendenza a org.eclipse.core.runtime.compatibility, se necessario.
Se si indica il plugin utilizzato come 3.0 (utilizzando <?eclipse version="3.0"?>) e il plugin definisce una classe Plugin, è necessario eseguire esplicitamente il comando <import plugin="org.eclipse.core.runtime.compatibility"/> nel file manifest del plugin o accertarsi che la classe Plugin definisca il costruttore predefinito.
Nota: questa è una delle incompatibilità che non influisce sul modo in cui i plugin binari 2.1 vengono eseguiti da Eclipse 3.0. Il runtime di Eclipse 3.0 individua automaticamente i plugin precedenti alla versione 3.0 (dall'assenza della riga <?eclipse version="3.0"?> nel file manifest del plugin) e compensa automaticamente le modifiche al runtime della piattaforma.
Il plugin org.eclipse.xerces non è più necessario ed è stato eliminato. Il supporto di analisi XML viene generato su J2SE 1.4 e la presenza del plugin Xerces crea conflitti nel caricatore di classi. I pacchetti API javax.xml.parsers, org.w3c.dom.* e org.xml.sax.* forniti in precedenza dal plugin org.eclipse.xerces sono ora disponibili nelle librerie J2SE.
Se il plugin utilizzato richiede il plugin org.eclipse.xerces, è necessario modificare il file manifest del plugin per rimuovere questa dipendenza definita. Una volta eseguita questa operazione, il codice del plugin deve essere compilato ed eseguito senza ulteriori modifiche.
I plugin binari 2.1 con una dipendenza definita sul plugin org.eclipse.xerces non presentano un prerequisito quando eseguiti in una configurazione Eclipse 3.0 standard. Come conseguenza, il plugin non sarà attivato.
Prima di Eclipse 3.0, Eclipse funzionava soprattutto in un un singolo thread. Molti metodi e punti di estensione delle API funzionavano o nel thread dell'UI o nel thread di una finestra di dialogo di avanzamento che bloccava il thread dell'UI. Molti sviluppatori di plugin non dovevano preoccuparsi della sicurezza del thread, a parte garantire che tutte le attività dell'UI si verificassero nel thread dell'UI. In Eclipse 3.0, esiste in genere maggiore simultaneità. Molte operazioni si verificano ora in un thread di sfondo, dove possono essere eseguite contemporaneamente ad altri thread, incluso il thread dell'UI. Tutti i plugin il cui codice viene eseguito nel thread di sfondo devono essere consapevoli della sicurezza del thread del relativo codice.
Oltre ai plugin che eseguono esplicitamente operazioni sullo sfondo utilizzando l'API org.eclipse.core.runtime.jobs
, esistono varie funzioni API della piattaforma e punti di estensione che utilizzano i thread di sfondo. I plugin che utilizzano queste funzioni devono garantire che il codice presenti la sicurezza thread. Nella tabella di seguito riportata vengono riepilogate le API e i punti di estensioni che eseguono alcuni o tutti i codici in un thread di sfondo di Eclipse 3.0:
Punto di estensione o classe API |
Note |
org.eclipse.core.runtime.IRegistryChangeListener | Nuovo in Eclipse 3.0, viene eseguito sullo sfondo |
org.eclipse.core.resources.IResourceChangeListener | Eventi AUTO_BUILD ora eseguiti sullo sfondo |
org.eclipse.core.resources.builders (punto di estensione) | Generazione automatica ora sullo sfondo |
org.eclipse.core.resources.ISaveParticipant | SNAPSHOT ora sullo sfondo |
org.eclipse.workbench.texteditor.quickdiffReferenceProvider (punto di estensione) | Nuovo in Eclipse 3.0, viene eseguito sullo sfondo |
org.eclipse.ui.decorators (punto di estensione) | Già sullo sfondo in Eclipse 2.1 |
org.eclipse.ui.startup (punto di estensione) | Già sullo sfondo in Eclipse 2.1 |
org.eclipse.team.core.org.eclipse.team.core.repository (punto di estensione) | Molte operazioni ora sullo sfondo |
org.eclipse.team.ui.synchronizeParticipants (punto di estensione) | Nuovo in Eclipse 3.0, viene eseguito sullo sfondo |
org.eclipse.debug.core.launchConfigurationTypes (punto di estensione) | Ora eseguito sullo sfondo |
org.eclipse.jdt.core.IElementChangedListener | ElementChangedEvent.PRE_AUTO_BUILD ora eseguito sullo sfondo, POST_RECONCILE già eseguito sullo sfondo |
Esistono varie strategie disponibili per la creazione della sicurezza thread del codice. Una soluzione semplice è garantire che tutto il lavoro si verifichi nel thread dell'UI, assicurando così l'esecuzione in serie. Questo è un approccio comune per i plugin dell'UI che non effettuano l'esecuzione intensiva della CPU. In questo caso, è necessario essere consapevoli del rischio deadlock inerente a Display.syncExec
. Display.asyncExec
è in genere più sicuro in quanto non introduce il rischio deadlock, a spese del controllo preciso sul momento in cui il codice viene eseguito.
Altre tecniche per la creazione del codice di sicurezza del thread includono:
org.eclipse.core.runtime.jobs.ILock
.
Il vantaggio di ILock
sui blocchi generici sta nel fatto che vengono trasferiti automaticamente al thread dell'UI quando si esegue un syncExec
ed esiste un supporto di rilevazione deadlock generato nell'implementazione che registra e risolve i deadlock.Display.asyncExec
), elaborata interamente nel thread dell'UI.java.lang.String
e org.eclipse.core.runtime.IPath
. Il vantaggio degli oggetti immutabili è rappresentato da un accesso in lettura estremamente rapido, a costo di un lavoro supplementare al momento della modifica.I metodi di seguito riportati sono stati eliminati dall'interfaccia org.eclipse.ui.IWorkbenchPage. IWorkbenchPage viene definito nel workbench generico, ma i metodi sono specifici delle risorse.
I client dei metodi IWorkbenchPage.openEditor devono invece richiamare i metodi public static corrispondenti nella classe org.eclipse.ui.ide.IDE (nel plugin org.eclipse.ui.ide).
I client dei metodi IWorkbenchPage.openSystemEditor(IFile) devono convertire IFile in IEditorInput utilizzando un nuovo FileEditorInput(IFile), quindi richiamare il metodo (IEditorInput,String). In altre parole, riscrivere page.openSystemEditor(file) come page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Nota: i client che utilizzano l'id dell'editor IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID devono trasferire un input dell'editor che implementi org.eclipse.ui.IPathEditorInput (come FileEditorInput).
Nota: questa è una delle incompatibilità che non influisce sul modo in cui i plugin binari 2.1 vengono eseguiti da Eclipse 3.0. Eclipse 3.0 include un meccanismo di compatibilità di runtime binaria che garantisce che i file binari del plugin 2.1 esistenti che utilizzano uno dei metodi openEditor e openSystemEditor eliminati continuino a funzionare come nella versione 2.1, nonostante la modifica di questa API. (I metodi eliminati sono in realtà "aggiunti di nuovo" dal frammento org.eclipse.ui.workbench.compatibility).Il metodo di seguito riportato è stato eliminato dall'interfaccia org.eclipse.ui.IEditorPart. IEditorPart viene definito nel workbench generico, ma il metodo è specifico delle risorse.
I client che richiamano questo metodo devono invece verificare se la parte dell'editor implementa o si adatta a org.eclipse.ui.ide.IGotoMarker (nel plugin org.eclipse.ui.ide) e, in questo caso, richiamare gotoMarker(IMarker). La classe IDE presenta un metodo appropriato: IDE.gotoMarker(editor, marker);
I client che implementano un editor che possono essere posizionati in base alle informazioni su IMarker devono implementare o adattarsi a org.eclipse.ui.ide.IGotoMarker.Poiché l'unico metodo di IGotoMarker è gotoMarker(IMarker) e presenta la stessa firma e specifica del vecchio IEditorPart.gotoMarker(IMarker), le implementazioni dell'editor esistenti possono adattarsi a questa modifica semplicemente includendo IGotoMarker nella proposizione di implementazione della definizione di classe.
I plugin binari 2.1 con un codice che richiama questo metodo visualizzano un errore di collegamento classe quando eseguiti in una configurazione Eclipse 3.0 standard.
L'interfaccia dell'utilità di avvio dell'editor org.eclipse.ui.IEditorLauncher viene implementata dai plugin che forniscono gli editor esterni. Il metodo di seguito riportato è stato rimosso da questa interfaccia. IEditorLauncher viene definito nel workbench generico, ma il metodo è specifico delle risorse.
È stato sostituito da
I plugin binari 2.1 con un codice che richiama questo metodo visualizzano un errore di collegamento classe quando eseguiti in una configurazione Eclipse 3.0 standard.
I metodi di seguito riportati sono stati rimossi dall'interfaccia org.eclipse.ui.IEditorRegistry. IEditorRegistry viene definito nel workbench generico, ma i metodi sono specifici delle risorse.
Esistono nuove costanti che rappresentano gli identificativi dell'editor esterno del sistema e dell'editor interno del sistema (SYSTEM_EXTERNAL_EDITOR_ID e SYSTEM_INPLACE_EDITOR_ID). Questi due editor richiedono un input che implementi o si adatti a org.eclipse.ui.IPathEditorInput. Il descrittore dell'editor interno non esiste nelle configurazioni Eclipse che non supportano editor interni.
Il metodo di seguito riportato è stato eliminato dall'interfaccia org.eclipse.ui.IWorkbench. IWorkbench viene definito nel workbench generico, ma il metodo è specifico delle risorse.
I plugin binari 2.1 con un codice che richiama questo metodo visualizzano un'eccezione quando eseguiti in una configurazione Eclipse 3.0 standard.
Per rendere org.eclipse.ui.texteditor.AbstractTextEditor indipendente da IFile, org.eclipse.ui.texteditor.AbstractDocumentProvider introduce il concetto di operazioni del fornitore documenti (DocumentProviderOperation) e di un programma di esecuzione di operazioni del fornitore documenti (IRunnableContext). Quando è necessario eseguire operazioni di reimpostazione, salvataggio o sincronizzazione, AbstractDocumentProvider crea operazioni del fornitore documenti ed utilizza il programma di esecuzione per eseguire tali operazioni. Il contesto eseguibile può essere fornito dalle sottoclassi mediante il metodo getOperationRunner. Di seguito viene riportato un riepilogo delle modifiche che i client devono adattare a:
La sottoclasse AbstractDocumentProvider org.eclipse.ui.editors.text.StorageDocumentProvider implementa il metodo getOperationRunner in modo che restituisca sempre un valore null. Ciò significa che le sottoclassi di StorageDocumentProvider non devono essere influenzate da questa modifica.
La sottoclasse StorageDocumentProvider org.eclipse.ui.editors.text.FileDocumentProvider implementa il metodo getOperationRunner che restituisce un IRunnableContext per l'esecuzione di DocumentProviderOperations all'interno di WorkspaceModifyOperation. Altre modifiche a FileDocumentProvider sono:
Modifiche a org.eclipse.ui.texteditor.AbstractTextEditor:
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
La sottoclasse AbstractTextEditor org.eclipse.ui.texteditor.StatusTextEditor fornisce il metodo predicato isErrorStatus(IStatus). Le sottoclassi devono essere sostituite per stabilire se un determinato stato deve essere considerato un errore o meno.
Modifiche a org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:
Come parte dell'introduzione del supporto annotazioni senza intestazione, sono state apportate le seguenti modifiche all'annotazione:
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
Eclipse 3.0 presenta un nuovo supporto per la console generica. La console generica è disponibile selezionando Finestra > Mostra vista > Di base > Console e viene utilizzata dal debug Eclipse e dall'integrazione Ant.
L'id della vista per la console è stato modificato da org.eclipse.debug.ui.ConsoleView a org.eclipse.ui.console.ConsoleView. I plugin 2.1 che aprono in modo programmatico la console non funzionano, perché la vecchia vista non esiste più.
In 3.0, i tipi di restituzione per i metodi org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) e installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) sono stati modificati da booleani a int per consentire ai listener di scegliere il valore "don't care". Nei rilasci precedenti al 3.0, i listener potevano scegliere solo i valori "suspend" o "don't suspend", quando veniva selezionato un punto di interruzione e "install" o "don't install" quando un punto di interruzione veniva installato. Nella versione 3.0, i listener possono scegliere anche il valore "don't care" per queste notifiche. Ciò consente ai client di eseguire una scelta decisiva in situazioni importanti. Per le notifiche "breakpoint hit", i punti di interruzione vengono sospesi se un listener sceglie "suspend" o tutti i listener scelgono "don't care" e viene sospeso se almeno un listener sceglie "don't suspend" e nessun listener sceglie "suspend". Allo stesso modo, per le notifiche "breakpoint installing", il punto di interruzione viene installato se un listener sceglie l'installazione o tutti i listener scelgono "don't care" e non viene installato se almeno un listener sceglie "don't install" e nessun listener sceglie "install". In generale, gli implementatori devono restituire il valore DONT_CARE, a meno che non abbiano una forte propensione per uno o per l'altro valore. È importante ricordare, ad esempio, che scegliendo "suspend" vengono sostituite tutte le altre selezioni "don't suspend" del listener.
L'interfaccia IJavaBreakpointListener viene implementata dai client che creano o reagiscono ai punti di interruzione nel codice Java. Esistono pochi client oltre JDT, salvare il client che ha riportato il problema (bug 37760) che questa modifica consente di eliminare. Questa è una modifica di interruzione per il codice esistente che implementa l'interfaccia IJavaBreakpointListener. Questo codice deve essere modificato per restituire un valore int appropriato prima che venga compilato o eseguito nella versione 3.0.
Prima della versione 3.0, l'esecuzione dei metodi della classe SWT org.eclipse.swt.dnd.Clipboard era tacitamente consentita in thread diversi dal thread dell'UI. Ciò determinava errori in GTK, in cui il sistema operativo richiede che tutte le interazioni degli appunti siano eseguite nel thread dell'UI. Questi errori non erano rivelati prima, in quanto molte applicazioni sono a singolo thread e ricevono gran parte delle loro verifiche su Windows. Affinché l'API degli appunti sia sostenibile e utilizzabile su varie piattaforme, nella versione 3.0 la specifica e l'implementazione di tutti i metodi dell'API degli appunti sono state modificate, per visualizzare un'eccezione SWT (ERROR_THREAD_INVALID_ACCESS), se richiamati da un thread non UI. I servizi degli appunti sono in genere forniti dai componenti Eclipse automaticamente, ad esempio gli editor di testo, che isolano molti client da questa modifica di interruzione. Il codice esistente che fa un uso diretto degli appunti deve garantire che i metodi API siano richiamati sul thread corretto, utilizzando Display.asyncExec o syncExec quando appropriato per consentire l'accesso nel thread dell'UI.
Nella versione 3.0, SWT riporta gli eventi che si verificano premendo un tasto prima che il lavoro venga eseguito nel sistema operativo. Questo accade molto prima di quanto accadesse prima della versione 3.0. Questa modifica è stata apportata per supportare le associazioni ai tasti in Eclipse che devono intercettare gli eventi relativi ai tasti premuti prima che un widget possa elaborare il carattere. Le conseguenze di questa modifica sono visibili sul codice che gestisce direttamente gli eventi org.eclipse.swt.SWT.KeyDown di livello basso. Ad esempio, ciò significa che quando un listener su un widget di testo riceve un evento relativo ad un tasto premuto, il contenuto del widget (getText()) non include il tasto appena digitato (ciò si verificava prima della versione 3.0). Per richiamare il testo completo dal widget, incluso il tasto corrente,è opportuno gestire gli eventi SWT.Modify o SWT.Verify di livello più alto anziché l'evento SWT.KeyDown di livello basso; il codice che già effettua questa attività non è influenzato da questa modifica.
Prima della versione 3.0, quando era attiva la classe SWT org.eclipse.swt.widgets.Canvas o una delle relative sottoclassi (inclusi i widget personalizzati), immettendo Ctrl+Tab, Maiusc+Tab, Ctrl+PgSu o Ctrl+PgGiù si attivava automaticamente il passaggio al widget precedente/successivo senza riportare un evento relativo alla posizione dei tasti. Questo comportamento non era specificato e contrava con la regola secondo la quale i Canvas visualizzano tutti i tasti digitati. Il modo corretto per gestire il passaggio è registrare un listener di passaggio. Per supportare correttamente le associazioni ai tasti Eclipse nella versione 3.0, il comportamento predefinito è stato modificato in modo che Canvas visualizzi ora gli eventi relativi ai tasti Ctrl+Tab, Maiusc+Tab, Ctrl+PgSu, e Ctrl+PgGiù. Se si utilizza un Canvas di base o si definisce una sottoclasse di Canvas, registrare un listener di passaggio.
Le selezioni mediante mouse di elementi nelle classi SWT org.eclipse.swt.widgets.Table e Tree generano la sequenza di eventi MouseDown-Selection-MouseUp in tutti i sistemi operativi. Allo stesso modo, le selezioni dalla tastiera generano la sequenza di eventi KeyDown-Selection-KeyUp in tutti i sistemi operativi. Prima della versione 3.0, l'ordine degli eventi non era uniforme, con Motif e Photon in disaccordo, riportando sempre prima l'evento Selection, ad esempio, Selection-MouseDown-MouseUp o Selection-KeyDown-KeyUp. Nella versione 3.0, l'ordine degli eventi su Motif e Photon è stato modificato per corrispondere agli altri. Il codice esistente che funzionava correttamente su {Windows, GTK} e su {Motif, Photon} è improbabile che ne venga influenzato. È tuttavia opportuno controllare il codice per verificare che si basi su un ordine di eventi non valido.
org.eclipse.core.runtime.IStatus
presenta una nuova costante di gravità, IStatus.CANCEL
, che può essere utilizzata per indicare l'annullamento. Coloro che richiamano IStatus.getSeverity()
,
che si basa sull'insieme di possibili livelli di gravità limitati a IStatus.OK
,
INFO
, WARNING
e ERROR
sono influenzati da questa aggiunta. Coloro che richiamano
getSeverity
devono aggiornare il codice per includere il nuovo livello di gravità.
In Eclipse 3.0, le generazioni automatiche dello spazio di lavoro si verificano in un thread di sfondo. Ciò richiede una modifica del contratto API su org.eclipse.core.resources.IResourceChangeEvent
. Il contratto di IResourceChangeEvent
garantiva prima l'ordine di eventi di seguito riportato per tutte le modifiche dello spazio di lavoro:
PRE_DELETE
o PRE_CLOSE
, se applicabilePRE_AUTO_BUILD
POST_AUTO_BUILD
POST_CHANGE
Con la generazione automatica ora in esecuzione sullo sfondo, non esiste più alcuna garanzia sulla relazione temporale tra gli eventi AUTO_BUILD
e l'evento
POST_CHANGE
. In Eclipse 3.0, le fasi 3-5 della struttura sopra riportata sono rimossi dall'operazione. L'immagine risultante è la seguente:
PRE_DELETE
o PRE_CLOSE
, se applicabilePOST_CHANGE
Periodicamente, la piattaforma esegue un'operazione di generazione dello spazio di lavoro sullo sfondo. Ciò si verifica indipendentemente dal fatto che la generazione automatica sia attiva o disattiva. Non viene specificato il momento esatto in cui si verifica questa generazione. La struttura dell'operazione di generazione è la seguente:
PRE_BUILD
(PRE_BUILD
è il nuovo nome per PRE_AUTO_BUILD)
POST_BUILD
(POST_BUILD
è il nuovo nome per POST_AUTO_BUILD)
POST_CHANGE
Il punto di riferimento per i delta ricevuti dai listener di generazione automatica sarà diverso dai listener successivi alla modifica. I listener di generazione ricevono la notifica di tutte le modifiche dalla fine dell'ultima operazione di generazione. I listener successivi alla modifica ricevono un delta che descrive tutte le modifiche dall'ultima notifica successiva alla modifica. Questa nuova struttura conserva tre caratteristiche dei listener di modifica delle risorse presenti da Eclipse 1.0:
POST_CHANGE
ricevono la notifica di tutte le modifiche delle risorse che si verificano durante il tempo in cui sono registrati. Sono incluse le modifiche apportate dai generatori e le modifiche apportate da altri listener.PRE_AUTO_BUILD
ricevono la notifica di tutte le modifiche delle risorse eccetto le modifiche apportate dai generatori e dai listener di modifica delle risorse.POST_AUTO_BUILD
ricevono la notifica di tutte le modifiche delle risorse eccetto le modifiche apportate da altri listener POST_AUTO_BUILD
.Tuttavia, vi sono alcune importanti differenze con questo approccio. Prima di
Eclipse 3.0, i listener di generazione automatica erano sempre richiamati prima dei listener POST_CHANGE
. Per questo motivo, il delta ricevuto dai listener di generazione automatica era sempre un sottinsieme di delta ricevuti dai listener POST_CHANGE
.
Questa relazione è ora invertita. I listener di generazione automatica ricevono un delta che rappresenta un superinsieme di tutti i delta forniti ai listener POST_CHANGE
, dalla fine dell'ultima generazione di sfondo. Come prima, ai listener di generazione automatica è consentito modificare lo spazio di lavoro, a differenza dei listener successivi alla modifica.
Non è più valido il concetto per cui, al completamento di un'operazione di modifica di uno spazio di lavoro, i listener di eventi AUTO_BUILD
sono stati notificati.
Il nodo client che registra i listener di modifica delle risorse con IWorkspace.addResourceChangeListener(IResourceChangeListener)
non viene influenzato da questa modifica, perché gli eventi AUTO_BUILD
non vengono mai riportati a questi listener. Tuttavia, i client che utilizzano IWorkspace.addResourceChangeListener(IResourceChangeListener,int)
e specificano una maschera di eventi che include gli eventi AUTO_BUILD
è probabile che vengano interrotti da questa modifica, se effettuano ipotesi sul momento in cui i listener di generazione automatica vengono eseguiti o su quali thread vengono eseguiti. Ad esempio, se un listener di generazione automatica aggiorna un modello di dominio per riflettere le modifiche allo spazio di lavoro, questo aggiornamento può non essere eseguito quando viene restituita l'operazione di modifica dello spazio di lavoro. Non ha alcun valore che il codice di livello UI possa essere influenzato in questo modo. Il codice di livello principale richiamato mediante l'API può essere richiamato nell'ambito di un IWorkspaceRunnable
, per cui non è mai possibile stabilire il momento in cui verranno richiamati i listener di modifica delle risorse. La correzione consigliata è utilizzare POST_CHANGE
al posto dei listener di generazione, se è necessario che la notifica si verifichi prima del completamento dell'operazione.
Non è più garantito che venga eseguito il batch di tutte le modifiche delle risorse che si verificano durante l'ambito dinamico di un IWorkspaceRunnable
in una singola notifica. Questo meccanismo può ancora essere utilizzato per eseguire il batch delle modifiche ed evitare generazioni e notifiche non necessarie, ma la piattaforma può ora stabilire di eseguire delle notifiche durante le operazioni. La modifica del contratto API non è una modifica di interruzione per i client esistenti. È equivalente alla piattaforma che decide di richiamare IWorkspace.checkpoint
periodicamente durante le operazioni di lunga durata. Il motivo di questa modifica sta nel fatto che è ora possibile per più thread modificare lo spazio di lavoro contemporaneamente. Quando un thread termina la modifica dello spazio di lavoro, viene richiesta una notifica per evitare problemi di responsabilità, anche se le altre operazioni non sono state ancora completate. Questa modifica consente agli utenti di iniziare a lavorare su un insieme di risorse prima del completamento delle operazioni. Ad esempio, un utente può ora iniziare a selezionare i file di un progetto che è ancora in corso di estrazione. Il nuovo metodoIWorkspace.run(IWorkspaceRunnable,
ISchedulingRule, int, IProgressMonitor)
presenta un indicatore facoltativo, AVOID_UPDATE
,
che le operazioni possono utilizzare come suggerimento per la piattaforma per specificare se sono desiderati aggiornamenti periodici.
Elementi interessati: Plugin che forniscono estensioni al punto di estensione org.eclipse.core.runtime.urlHandlers
.
Descrizione: Il contratto per il punto di estensione org.eclipse.core.runtime.urlHandlers
è stato modificato per utilizzare il servizio URL Stream Handler fornito da OSGi. Il supporto OSGi è superiore al supporto di Eclipse 2.1 e gestisce correttamente i gestori dinamici. A causa dei vari problemi di struttura con il meccanismo di base del gestore URL Java, gli elementi URLStreamHandlers registrati con il servizio del gestore OSGi devono implementare org.osgi.service.url.URLStreamHandlerService
.
Azione richiesta: In passato, la classe del gestore doveva implementare java.net.URLStreamHandler
ed estendere il punto di estensione urlHandlers. Il punto di estensione non è più supportato e il gestore deve essere aggiornato per implementare l'interfaccia org.osgi.service.url.URLStreamHandlerService
. Il framework OSGi fornisce una classe di base astratta (org.osgi.service.url.AbstractURLStreamHandlerService
)
che può essere semplicemente suddivisa in sottoclassi per soddisfare questo ruolo.
Anziché registrare il gestore utilizzando un punto di estensione, i plugin devono ora eseguire questa operazione registrando il gestore come un servizio. Ad esempio,
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);
Elementi interessati: I plugin che forniscono i pacchetti forniti anche da altri plugin. Un numero molto limitato di plugin è interessato da questa modifica e alcuni di tali plugin ne traggono effettivamente beneficio (vedere sotto).
Descrizione: In Eclipse 2.x, i caricatori di classi ricercano le classi nel seguente ordine: consultano (1) il caricatore di classi principale (in pratica, il caricatore di classi di avvio, quindi (2) il contenuto del percorso classi e infine (3) tutti i prerequisiti nell'ordine specificato. OSGi offre un'ottimizzazione per questo modello. In questo approccio un caricatore classi consulta (1) il caricatore classi principale (in realtà il caricatore classi di avvio Java), quindi (2a) un singolo prerequisito conosciuto per fornire le classi nel pacchetto da interrogare o (2b) le voci del percorso classi per la classe desiderata.
Il caricatore classi stabilisce se consultare i prerequisiti in base ai pacchetti importati e richiesti. Queste informazioni vengono dedotte dal contenuto del plugin nel caso di plugin tradizionali e direttamente specificate nel caso di plugin con file manifest esplicito dell'insieme OSGi. In entrambi i casi, viene riconosciuta una priorità che i caricatori classi fornisce alle classi per i pacchetti. Ciò consente di migliorare le prestazioni e rappresenta una soluzione al fastidioso problema di più prerequisiti che forniscono le stesse classi.
Si prenda ad esempio il caso di Xerces e Xalan, entrambi contenenti varie classi del pacchetto org.xml. Utilizzando il primo approccio, il plugin Xerces visualizza la propria copia di queste classi, mentre il plugin Xalan visualizza le copie delle classi. Poiché questi plugin devono comunicare, si verificano le eccezioni ClassCastExceptions. Utilizzando il secondo approccio, solo uno dei due plugin fornisce le classi duplicate e entrambi i plugin visualizzano le stesse copie.
Azione richiesta: L'azione richiesta dipende dai particolari del caso di utilizzo. Gli sviluppatori interessati devono rivedere il percorso classi e risolvere i conflitti che possono verificarsi.
Elementi interessati: I plugin che prevedono che il dominio di protezione del caricatore classi venga impostato ogni volta.
Descrizione: In Eclipse 2.1, i caricatori classi del plugin erano java.security.SecureClassloaders e, come tali, avevano sempre un dominio di protezione impostato. In Eclipse 3.0, i caricatori classi non estendono SecureClassloader e impostano il dominio di protezione solo se la sicurezza Java è attivata (non nel caso normale).
Azione richiesta: L'azione richiesta dipende dallo scenario in cui il plugin utilizza il dominio di protezione.
Elementi interessati: I plugin che eseguono il cast degli oggetti di tipo org.eclipse.core.runtime.IPlugin* in org.eclipse.core.runtime.model.Plugin*Model. Anche se la relazione tra queste interfacce e le classi di modelli non è specificata nell'API di Eclipse 2.1, questa modifica viene richiamata esplicitamente, in quanto nell'implementazione 2.1 sono state individuate istanze di plugin che si basano su questa relazione.
Descrizione: L'API di Eclipse fornisce una serie di interfacce (ad esempio, IPluginDescriptor
) e cosiddette classi di "modelli" (ad esempio, PluginDescriptorModel
) relative ai plugin e al registro dei plugin. Nell'implementazione di Eclipse 2.1, le classi di modelli implementano le interfacce rilevanti. Nel nuovo runtime basato su OSGi, il registro di plugin è stato significativamente rielaborato, per consentire una separazione tra il caricamento delle classi, gli aspetti prerequisiti dei plugin e gli aspetti delle estensioni e dei punti di estensione. Il runtime di Eclipse 3.0 non è in grado di mantenere la relazione di implementazione presente nella versione 2.1.
Azione richiesta: Il codice dei plugin che si basano su questa relazione non API deve essere rielaborato in base al caso di utilizzo. Più informazioni su questo argomento sono fornite nella sezione relativa alle modifiche consigliate di questo documento e nel Javadoc relativo alle classi e ai metodi correlati.
Elementi interessati: Plugin che utilizzano org.eclipse.core.runtime.ILibrary
.
Descrizione: Il nuovo runtime mantiene le voci del percorso classi in un formato diverso e incompatibile da Eclipse. Come risultato, il livello di compatibilità non è in grado di modellare correttamente le strutture OSGi sottostanti come oggetti ILibrary. Il supporto di compatibilità del runtime crea oggetti ILibrary ma deve utilizzare valori predefiniti per qualsiasi elemento, eccetto che per il percorso della libreria.
Azione richiesta: Gli utenti di ILibrary devono considerare l'accesso ai valori di intestazione desiderati (ad esempio, Bundle-Classpath
) dall'insieme appropriato (fare riferimento a Bundle.getHeaders()
) e utilizzare la classe della guida ManifestElement
per interpretare le voci. Per ulteriori dettagli, vedere il Javadoc della classe.
Elementi interessati: I plugin che fanno supposizioni relative alla struttura di installazione, al percorso e al layout del file system locale.
Descrizione: I metodi quali IPluginDescriptor.getInstallURL()
restituiscono gli URL di un determinato formato. Nonostante il formato non sia specificato, vari plugin fanno supposizioni in base all'implementazione corrente. Ad esempio, possono prevedere di visualizzare un file:
URL.getFile() e di utilizzare la modifica java.io.File
sul risultato. Questo approccio funziona ma è piuttosto debole. Ad esempio, se un plugin è installato su un server web, è possibile che venga restituito un URL http:
. Il nuovo runtime di Eclipse 3.0 è anche più flessibile e apre più possibilità per le configurazioni di esecuzione
(ad esempio, mantenendo i plugin nei JAR anziché inserirli nelle directory).
Ciò significa che, mentre il nuovo runtime basato su OSGi non interrompe l'API 2.1, presenta molti casi in cui le supposizioni fatte nei plugin correnti non sono valide.
Azione richiesta: Coloro che compongono i plugin devono garantire che le informazioni alle quali devono accedere siano disponibili mediante getResource()
(e si trovano nel percorso classi) o utilizzare l'API più importante per accedere al contenuto di un plugin (ad esempio, Bundle.getEntry(String)
).
Elementi interessati: Il codice non di plugin che richiama determinati metodi dalla classe org.eclipse.core.boot.BootLoader
.
Descrizione: I metodi statici BootLoader.startup(), shutdown() e run() sono stati spostati su org.eclipse.core.runtime.adaptor.EclipseStarter, che fa parte del framework OSGi. Questa API è l'interfaccia tra l'elemento main() in startup.jar e il framework OSGi/runtime Eclipse. La ristrutturazione del runtime non ha consentito di lasciare questi metodi su BootLoader. La vecchia classe BootLoader si trova ora nel livello di compatibilità del runtime ed è obsoleta e i metodi spostati non eseguono alcuna azione.
Non esiste alcuna sostituzione per il vecchio BootLoader.getRunnable(), dal momento che il runtime non può più supportare l'acquisizione delle singole applicazioni. Gli utenti devono quindi indicare l'applicazione di interesse quando avviano la piattaforma.
Azione richiesta: In generale, questa API viene utilizzata da poche persone (non può essere utilizzata all'interno di un plugin Eclipse). Nei rari casi in cui viene utilizzata in un plugin Eclipse, il codice deve essere adattato per utilizzare i metodi corrispondenti su EclipseStarter.
Elementi interessati: Tutti i plugin.
Descrizione: In Eclipse 2.1, la riga bin.includes di un plugin, richiamata dal file build.properties non doveva contenere l'elenco dei JAR proveniente dalla dichiarazione di libreria nel file plugin.xml; questi JAR erano aggiunti automaticamente. In Eclipse 3.0 l'elenco dei file della sezione bin.includes di build.properties è un elenco esauriente e deve includere tutti i file che gli sviluppatori dei plugin intendono includere nel propri plugin durante la generazione o l'esportazione.
Azione richiesta: Verificare che la riga bin.includes del file build.properties includa tutti i JAR elencati nel file plugin.xml.
Elementi interessati: Plugin che presentano l'API che include elementi dell'API di runtime modificata.
Descrizione: Vari plugin che presentano l'API che include elementi dell'API di runtime. Con le modifiche al runtime di Eclipse 3.0 illustrate, i plugin del client devono rivalutare l'utilizzo dell'API di runtime nelle relative API.
Azione richiesta: Questo scenario è abbastanza raro, in quanto molto poco delle API di runtime di Eclipse è stato modificato. A seconda dello scenario, i client devono modificare le relative API o continuare ad utilizzare il livello di compatibilità.
Elementi interessati: Plugin che utilizzano org.eclipse.core.runtime.Platform.parsePlugins(...,
Factory).
Descrizione: Il metodo org.eclipse.core.runtime.Platform.parsePlugins(...,
Factory)
è stato spostato. L'API associata all'argomento Factory è stata spostata dal plugin org.eclipse.core.runtime al plugin
org.eclipse.core.runtime.compatibility (che dipende dal plugin di runtime). Come risultato, è stato spostato anche il metodo di analisi.
Azione richiesta: Gli utenti di questo metodo devono utilizzare lo stesso metodo sulla classe org.eclipse.core.runtime.model.PluginRegistryModel
.
Elementi interessati: I plugin che specificano il codice nel percorso classi ma non forniscono quel codice (il JAR viene fornito da un frammento, ad esempio, il plugin org.eclipse.swt).
Descrizione: Il nuovo runtime deve convertire i file plug.xml nei file manifest.mf dietro le scene. Questa operazione viene eseguita mediante una semplice trasformazione meccanica ed un'analisi dei jar elencati e forniti dal plugin. Nel caso in cui un plugin specifichi un jar nel relativo percorso classi ma non fornisca il jar, non esiste alcun codice da analizzare e il convertitore di plugin non può generare un file manifest.mf corretto.
Azione richiesta: I fornitori di tali plugin devono essere modificati per fornire il jar appropriato nel plugin o creare/mantenere un file META-INF/MANIFEST.MF per il plugin. In genere, questa operazione può essere eseguita utilizzando PDE per visualizzare il file manifest iniziale e aggiungendo il file nell'intestazione fornitore-pacchetto appropriata.
Elementi interessati: Script (ad esempio, file Ant build.xml) che definiscono i percorsi delle classi contenenti i jar correlati al runtime e le directory delle classi.
Descrizione: Il nuovo runtime contiene diversi nuovi plugin e jar. La loro introduzione è stata imposta dal refactoring del runtime in parti configurabili. Per molte situazioni di runtime, queste modifiche sono trasparenti.
Tuttavia, se si dispone di script personalizzati build.xml (o simili) che compilano attualmente il codice su org.eclipse.core.runtime
, è necessario aggiornarli affinché funzionino correttamente. Uno script tipico contiene una voce del percorso classi in un'attività <javac> che fa riferimento al plugin org.eclipse.core.runtime
come segue:
../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar
Il plugin di runtime continua a contenere molto del codice di runtime originale.
Tuttavia, varie parti del runtime che si trovano in quella posizione solo per scopi di compatibilità, sono contenute in un plugin di compatibilità (org.eclipse.core.runtime.compatibility
).
La maggior parte del nuovo codice di runtime è contenuta in un insieme di plugin (org.eclipse.osgi.*
).
Azione richiesta: Gli sviluppatori devono aggiungere le voci in basso come necessario per eliminare gli errori di compilazione. Mentre l'insieme completo di jar fornito viene elencato in basso, l'utilizzo comune richiede solo un sottoinsieme sul percorso classi al momento della compilazione. Come sempre, l'inclusione delle directory /bin è a discrezione. Le voci vengono qui fornite in raggruppamenti logici dal plugin:
I seguenti jar possono essere richiesti in casi particolari:
Mentre si aggiornano questi script, è possibile anche eliminare i riferimenti (ad esempio mediante rimozione) a org.eclipse.core.boot
. Questo plugin è obsoleto e non contiene più alcun codice. Le voci possono essere lasciate sul percorso classi ma non hanno alcuno scopo e devono essere rimosse. Rimuovere:
../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar
Elementi interessati: Script (ad esempio, file Ant build.xml) che utilizzano l'attività eclipse.buildScript.
Descrizione: La generazione PDE ha introdotto una nuova proprietà nell'attività eclipse.buildScript per controllare la generazione degli script di generazione dei plugin. Ciò è imposto dall'introduzione del nuovo runtime basato su OSGi.
Azione richiesta: Se si desidera utilizzare Eclipse 3.0 per generare un prodotto basato sulla versione 2.1, introdurre in eclipse.buildScript la proprietà "buildingOSGi" e impostarla su false. Ad esempio:
<eclipse.buildScript ... buildingOSGi="false"/>
Elementi interessati: Script (ad esempio, file Ant build.xml) che utilizzano l'attività eclipse.buildScript.
Descrizione: La generazione PDE ha introdotto una nuova proprietà nell'attività eclipse.buildScript per controllare la generazione degli script di generazione dei plugin. Ciò è imposto dall'introduzione del nuovo runtime basato su OSGi.
Azione richiesta: Se si desidera utilizzare Eclipse 3.0 per generare un prodotto basato sulla versione 2.1, introdurre in eclipse.buildScript la proprietà "buildingOSGi" e impostarla su false. Ad esempio:
<eclipse.buildScript ... buildingOSGi="false"/>
Elementi interessati: Script (ad esempio, file Ant build.xml) che utilizzano l'attività eclipse.buildScript.
Descrizione: La generazione PDE ha modificato il comportamento dell'attività eclipse.fetch per semplificare la generazione di eclipse in uno stile di generazione automatizzato. Lo stile degli elementi supporta ora solo una voce alla volta e scriptName viene sempre ignorato.
Azione richiesta: Se si disponeva di un elenco di voci nel tag "elements" di una chiamata eclipse.fetch, diffondere queste voci su varie chiamate a eclipse.fetch. Se si imposta scriptName, lo script di recupero generato viene sempre chiamato "fetch_{elementId}". Ad esempio:
<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>
diventa
<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../> <eclipse.fetch elements="feature@org.eclipse.platform" .../>
Il file install.ini non è più incluso. Al suo posto si trova il nuovo file config.ini della sottodirectory di configurazione. I prodotti che utilizzavano il file install.ini per specificare una funzione principale (ad esempio, per fornire informazioni relative al marchio) devono apportare modifiche al file config.ini. Oltre al nuovo nomefile, sono stati modificati i nome dei tasti.
Il valore della chiave feature.default.id nella versione 2.1 deve essere impostato come il valore della nuova chiave eclipse.product. Il valore di eclipse.application deve essere impostato su "org.eclipse.ui.ide.workbench".
Infine, nella versione 2.1, l'immagine splash era sempre splash.bmp nella directory del plugin del marchio. Nella versione 3.0, il percorso dell'immagine splash viene fornito esplicitamente dalla chiave osgi.splashPath nel file config.ini.