FAQ relative alla migrazione dei plugin di Eclipse 3.0

Perché l'API di Eclipse è stata modificata tra le versioni 2.1 e 3.0 in modi incompatibili?

Eclipse 3.0 è un'evoluzione di Eclipse 2.1. Alcune aree non sono state modificate per mantenere una perfetta compatibilità con le versioni precedenti. Le quattro origini principali delle incompatibilità sono:

Elenco delle specifiche incompatibilità.

Un plugin 2.1 funziona in Eclipse 3.0?

Sì, eccetto alcuni casi. Se un plugin si basa solo sulle API Eclipse 2.1, continua a funzionare nella versione 3.0. Le poche eccezioni riguardano le API in cui le modifiche tra la versione 2.1 e 3.0 non possono essere eseguite in nessun modo compatibile; se un plugin utilizza una di queste modifiche, non funziona.

Il plugin 2.1 utilizza le classi dei pacchetti interni. Funzionerà in Eclipse 3.0?

Se un plugin si basa sulle classi interne o il comportamento non è specificato nell'API di Eclipse 2.1, è impossibile specificare se il plugin funzionerà nella versione 3.0. È necessario provarlo.

Come eseguire il plugin in Eclipse 3.0 senza toccarlo?

Installare il plugin 2.1 nella sottodirectory eclipse/plugins/ di un prodotto basato su Eclipse 3.0 e riavviare Eclipse. Eclipse riconosce che il plugin è un plugin 2.1 non convertito (dall'intestazione del file plugin.xml) ed automaticamente apporta le relative modifiche per compensare le modifiche alle dipendenze del plugin della piattaforma e ai punti di estensione della piattaforma ridenominata.

Un plugin 2.1 deve essere modificato per la corretta compilazione in Eclipse 3.0?

Sì, in tutti i casi. Esistono alcune differenze tra Eclipse 2.1 e 3.0 che necessitano di modifiche a tutti i plugin. Se si dispone di un plugin scritto per la versione 2.1 e si desidera ricompilarlo, è necessario che il plugin sia migrato alla versione 3.0 prima che venga ulteriormente sviluppato per la versione 3.0.

Quale procedura è necessario utilizzare per migrare il plugin a Eclipse 3.0?

Una volta caricato (o importato) il progetto plugin in uno spazio di lavoro di Eclipse 3.0, utilizzare Strumenti PDE > Migra a 3.0 (menu di scelta rapida del progetto) per convertire il file manifest del plugin al formato 3.0 e modificare automaticamente l'elenco dei plugin della piattaforma richiesti e i riferimenti ai punti di estensione della piattaforma ridenominati. In molti casi, il codice relativo al plugin viene compilato ed eseguito correttamente. Il codice relativo al plugin deve essere revisionato per verificare che non dipenda da una delle aree di modifiche API incompatibili.

Un plugin basato su API con modifiche incompatibili deve necessariamente presentare errori o avvertenze?

No. Alcune aree di modifiche incompatibili non vengono visualizzate dal compilatore Java.

È possibile ignorare avvertenze nel codice provenienti dall'uso di API obsolete?

Sì, in termini brevi. Quando possibile, le API obsolete vengono contrassegnate come tali anziché essere eliminate o continuare a funzionare (nonostante ciò sia possibile solo in condizioni limitate). Quindi, anche se non esiste alcuna urgenza di eliminare l'API obsoleta, il fatto che sia considerata obsoleta indica che esiste ora un modo migliore per eseguire quella determinata operazione. I plugin devono essere adattati alle API obsolete in base alla situazione più conveniente.

Una volta migrato il plugin su Eclipse 3.0, è ancora possibile installare ed eseguire il plugin binario risultante in Eclipse 2.1?

No. Questa operazione non è supportata e probabilmente non funziona a causa dei punti di estensione ridenominati.

Qual è lo scopo di org.eclipse.core.runtime.compatibility?

Lo spostamento nella versione 3.0 su un runtime basato su OSGi ha reso obsolete alcune API di runtime principali esistenti. Quando possibile, le API obsolete presenti nei pacchetti org.eclipse.core.runtime.*, insieme alla relativa implementazione, vengono spostate dal plugin org.eclipse.core.runtime in un nuovo plugin org.eclipse.core.runtime.compatibility. Per impostazione predefinita, i plugin appena creati dipendono da org.eclipse.core.runtime e utilizzano solo API di runtime non obsolete. D'altro canto, i plugin esistenti che vengono migrati dalla versione 2.1 dipendono per impostazione predefinita da org.eclipse.core.runtime.compatibility e possono utilizzare anche le vecchie API (il plugin org.eclipse.core.runtime.compatibility esporta nuovamente le API di org.eclipse.core.runtime). Mentre il plugin org.eclipse.core.runtime.compatibility viene probabilmente incluso nelle configurazioni IDE di Eclipse, è improbabile che venga incluso nei prodotti basati sulle configurazioni RCP.

Qual è lo scopo di org.eclipse.ui.workbench.compatibility?

org.eclipse.ui.workbench.compatibility è un frammento di plugin che fornisce la compatibilità binaria avanzata per l'esecuzione dei plugin 2.1 in un prodotto basato su Eclipse 3.0. Nella versione 3.0, sei metodi con una dipendenza esplicita su IFile o IMarker sono stati spostati dall'interfaccia org.eclipse.ui.IWorkbenchPage per separare il workbench dallo spazio di lavoro e dalle risorse. Il frammento org.eclipse.ui.workbench.compatibility ha lo scopo di aggiungere questi metodi, in modo che i plugin 2.1 esistenti possano essere eseguiti senza alcuna modifica. I plugin da migrare alla versione 3.0 che fanno riferimento ai metodi spostati visualizzano errori di compilazione che possono (solo) essere risolti richiamando i metodi di sostituzione ora presenti su org.eclipse.ui.ide.IDE.

I metodi IWorkbenchPage in questione sono: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) e openSystemEditor(IFile).