Varför har Eclipse API ändrats på ett inkompatibelt sätt mellan version 2.1 och 3.0?
Eclipse 3.0 är en utveckling av Eclipse 2.1. Det fanns några områden där vi inte kunde utveckla Eclipse och samtidigt behålla en perfekt kompatibilitet över hela linjen. De fyra huvudsakliga inkompatibilitskällorna är:
Listan med specifika inkompatibiliteter.
Kommer insticksprogram från version 2.1 att fungera i Eclipse 3.0?
Ja, förutom i några fall. Om ett insticksprogram endast är beroende av API:er i Eclipse 2.1 kommer det att fungera i version 3.0. De få undantagen är placerade i API:et där ändringarna mellan version 2.1 och 3.0 inte kunde göras på ett kompatibelt sätt. Om ett insticksprogram använder något av dessa API:er kommer insticksprogrammet inte att fungera.
Mitt insticksprogram från version 2.1 använder klasser i interna paket. Kommer det att fungera i Eclipse 3.0?
Om ett insticksprogram är beroende av interna klasser eller beteenden som inte är angivna i Eclipse 2.1 API:et, är det omöjligt att säga om insticksprogrammet kommer att fungera i 3.0. Du får helt enkelt testa.
Hur kör jag insticksprogrammet i Eclipse 3.0 utan att ändra det?
Installera insticksprogrammet från version 2.1 i underkatalogen eclipse/plugins/ i en Eclipse-baserad produkt och starta om Eclipse. Eclipse känner av (via huvudet i plugin.xml) att insticksprogrammet är ett insticksprogram från version 2.1 som inte har konverterats. Insticksprogrammet justeras automatiskt för att kompensera för ändringar av insticksprogrammets plattformsberoenden och namnändrade utökningspunkter i plattformen.
Måste insticksprogram från version 2.1 ändras för att de ska kunna kompileras på rätt sätt i Eclipse 3.0?
Ja, alltid. Det finns vissa olikheter mellan Eclipse 2.1 och 3.0 som kräver ändringar i alla insticksprogram som uppgraderas. Om du har ett insticksprogram som är skrivet för 2.1 och vill kompilera om det måste du migrera det till version 3.0 innan du kan fortsätta att utveckla det för version 3.0.
Hur migrerar jag insticksprogram till Eclipse 3.0?
När du har läst in (eller importerat) insticksprogrammet till arbetsytan i Eclipse 3.0 använder du PDE-verktyg > Migrera till 3.0 (projektets sammanhangsmeny) för att konvertera insticksprogrammets manifest till 3.0-format. Då justeras automatiskt listan med obligatoriska plattformsinsticksprogram och referensser till plattformens utökningspunkter som har fått nya namn. I de flesta fall kompileras och körs koden till insticksprogrammet utan problem. Du bör sedan granska koden för insticksprogrammet för att se till att den inte är beroende av någon av de inkompatibla API-områdena som har ändrats.
Kan jag lita på att kompileringsfel eller kompileringsvarningar uppstår i ett insticksprogram om det är beroende av ett API som har ändrats på ett inkompatibelt sätt?
Nej. Det finns vissa inkompatibilitetsändringar som inte flaggas av Java-kompilatorn.
Kan jag ignorera varningar i koden som kommer från ett utkommenterat API?
Ja, på kort sikt. Där det är möjligt markeras inaktuella API:er som utkommenterade i stället för att de tas bort helt och hållet och fortsätter att fungera (om än under begränsade förhållanden). Du kan fortfarande använda utkommenterade API:er, men i och med att ett API har blivit inaktuellt betyder det att det finns ett bättre sätt att göra något på. Insticksprogrammen bör rensas från all användning av utkommenterade API:er snarast möjligt.
När jag har migrerat insticksprogrammet till Eclipse 3.0 kan jag då fortfarande köra det binära insticksprogrammet i Eclipse 2.1?
Nej. Detta stöds inte och skulle troligtvis inte fungera eftersom utökningspunkterna har fått nya namn.
Vad är syftet med org.eclipse.core.runtime.compatibility?
Flytten i version 3.0 till en OSGi-baserad runtime gjorde vissa av API:erna i runtimekärnan inaktuella. Där det var möjligt har inaktuella API:er i org.eclipse.core.runtime.*-paket, tillsammans med implementeringen bakom, flyttats från insticksprogrammet org.eclipse.core.runtime till ett nytt insticksprogram, org.eclipse.core.runtime.compatibility. Som standard är nya insticksprogram beroende av org.eclipse.core.runtime och förväntas endast använda icke-utkommenterade runtime-API:er. Å andra sidan kommer befintliga insticksprogram som migreras från version 2.1 att vara beroende av org.eclipse.core.runtime.compatibility som standard. Dessa insticksprogram kan även använda de gamla API:erna (insticksprogrammet org.eclipse.core.runtime.compatibility exporterar API:erna i org.eclipse.core.runtime på nytt). Även om det är troligt att insticksprogrammet org.eclipse.core.runtime.compatibility inkluderas i Eclipse IDE-konfigurationer är det osannolikt att det inkluderas i produkter som är baserade på RCP-konfigurationer.
Vad är syftet med org.eclipse.ui.workbench.compatibility?
org.eclipse.ui.workbench.compatibility är ett insticksprogramfragment som ger bättre binär kompatibilitet för 2.1-insticksprogram som körs i en Eclipse 3.0-baserad produkt. I version 3.0 flyttades sex metoder med ett explicit beroende till IFile eller IMarker från gränssnittet org.eclipse.ui.IWorkbenchPage så att arbetsmiljön skulle kunna separeras från arbetsytan och resurserna på ett snyggt sätt. I fragmentet org.eclipse.ui.workbench.compatibility läggs dessa metoder tillbaka så att befintliga insticksprogram från version 2.1 kan köras utan att ändras. Observera att insticksprogram som migreras till version 3.0 och som hänvisar till de flyttade metoderna kommer att få kompileringsfel som endast kan lösas genom att ersättningsmetoderna, som nu finns i org.eclipse.ui.ide.IDE, anropas.
De IWorkbenchPage-metoder som berörs är: openEditor(IFile), openEditor(IFile, sträng), openEditor(IFile, sträng, boolesk), openEditor(IMarker), openEditor(IMarker, boolesk) och openSystemEditor(IFile).