Hvorfor ble APIet i Eclipse endret slik at det oppstod inkompatibilitet mellom 2.1 og 3.0?
Eclipse 3.0 er en utvikling av Eclipse 2.1. Det fantes noen få områder der vi ikke kunne utvikle Eclipse og samtidig opprettholde perfekt kompatibilitet. Dette er de fire viktigste kildene til inkompatibilitet:
Listen over spesifikke inkompatibiliteter.
Vil en 2.1-plugin fungere i 3.0?
Ja, bortsett fra noen få tilfeller. Hvis en plugin-modul bare avhenger av APIer fra Eclipse 2.1, vil den fortsette å fungere i 3.0. De svært få tilfellene er steder i APIet der endringene mellom 2.1 og 3.0 ikke kunne utføres på noen kompatibel måte. Hvis en plugin-modul bruker en av disse, vil den ikke fungere.
Min 2.1.plugin bruker klasser i interne klasser. Vil den likevel fungere i Eclipse 3.0?
Hvis en plugin-modul avhenger av interne klasser eller intern virkemåte som ikke er oppgitt i APIet for Eclipse 2.1, er det umulig å avgjøre hvor vidt plugin-modulen vil fungere i 3.0. Du må prøve det.
Hvordan kan jeg kjøre min plugin-modul i Eclipse 3.0 uten å røre den?
Installer plugin-modulen fra 2.1 i underkatalogen eclipse/plugins/ for et Eclipse 3.0-basert produkt, og start Eclipse på nytt. Eclipse vil gjenkjenne at plugin-modulen er en ukonvertert 2.1-plugin (ved hjelp av toppteksten for plugin.xml), og automatisk utføre justeringer for å kompensere for endringer i avhengighetene mellom plattformens plugin-moduler og plattformens utvidelsespunkter som har fått endret navnene.
Er det nødvendig å endre en 2.1-plugin for at den skal bli riktig kompilert i Eclipse 3.0?
Ja, i alle tilfeller. Det finnes bestemte forskjeller mellom Eclipse 2.1 og 3.0 som gjør det nødvendig å endre alle plugin-moduler som skal brukes. Hvis du har en plugin-modul som er skrevet for 2.1 og ønsker å kompilere den på nytt, må den migreres til 3.0 før den kan utvikles videre for 3.0.
Hvordan migrerer jeg min plugin-modul til Eclipse 3.0?
Når du har lastet inn (eller importert) plugin-prosjektet til et Eclipse 3.0-arbeidsområde, bruker du PDE-verktøy > Migrer til 3.0 (prosjektets hurtigmeny) til å konvertere plugin-modulens manifest til 3.0-formatet, og automatisk justere listen over nødvendige plugin-moduler for plattformen og referanser til plattformens utvidelsespunkter som har fått nytt navn. I de fleste tilfeller skal det da være mulig å kompilere og kjøre koden for plugin-modulen. Se gjennom koden for plugin-modulen for å forsikre deg om at den ikke er avhengig av ett av områdene med inkompatibel API-endring.
Kan jeg stole på at en plugin-modul har kompileringsfeil eller -advarsler hvis den er avhengig av API som er endret på en inkompatibel måte?
Nei. Det finnes noen områder med inkompatibel endring som ikke blir flagget av Java-kompilatoren.
Kan jeg trygt ignorere advarsler i koden som kommer fra bruken av foreldet API?
Ja, på kort sikt. Når det er mulig, merkes foreldede APIer som foreldet i stedet for at de slettes og arbeidet fortsetter (selv om det bare er mulig i noen få tilfeller). Så selv om det vanligvis ikke er noen hast å komme seg bort fra foreldet API, betyr det faktum at den nå blir betraktet som foreldet, at det finnes en bedre måte å gjøre ting på. Plugin-moduler bør slutte å bruke foreldede APIer så snart som mulig.
Når jeg har migrert plugin-modulen til Eclipse 3.0, kan jeg likevel installere og kjøre den resulterende binære plugin-modulen i Eclipse 2.1?
Nei. Dette støttes ikke, og det vil sannsynligvis ikke fungere på grunn utvidelsespunktene som har fått nytt navn.
Hva er formålet med org.eclipse.core.runtime.compatibility?
Flyttingen i 3.0 til en OSGi-basert kjøretid, gjorde noen av den eksisterende kjernekjøretidens APIer foreldede. Så sant det er mulig, er foreldede APIene i org.eclipse.core.runtime.*-pakkene, sammen med implementeringen bak dem, flyttet fra plugin-modulen org.eclipse.core.runtime til en ny org.eclipse.core.runtime.compatibility-plugin. Som standard avhenger nylig opprettede plugin-moduler av org.eclipse.core.runtime, og det forventes at de bare bruker ikke-foreldede kjøretids-APIer. På den andre siden vil eksisterende plugin-moduler som migreres fra 2.1, som standard avhenge av org.eclipse.core.runtime.compatibility, og de kan også bruke de gamle APIene (plugin-modulen org.eclipse.core.runtime.compatibility eksporterer APIer for org.eclipse.core.runtime på nytt). Mens plugin-modulen org.eclipse.core.runtime.compatibility sannsynligvis blir inkludert i Eclipse IDE-konfigurasjoner, er det lite sannsynlig at den blir inkludert i produkter som er basert på RCP-konfigurasjoner.
Hva er hensikten med org.eclipse.ui.workbench.compatibility?
org.eclipse.ui.workbench.compatibility er et plugin-fragment som sørger for forbedret kompatibilitet for plugin-moduler fra 2.1 som kjøres i et Eclipse 3.0-basert produkt. I 3.0 ble seks metoder med en eksplisitt avhengighet av IFile eller IMarker, flyttet fra org.eclipse.ui.IWorkbenchPage-grensesnittet for å skille arbeidsbenken fra arbeidsområdet og ressursene. Fragmentet org.eclipse.ui.workbench.compatibility legger disse metodene tilbake, slik at eksisterende plugin-moduler fra 2.1 kan kjøre uten endring. Vær oppmerksom på at plugin-moduler som er migrert til 3.0 som har referanser til de flyttede metodene, vil se kompileringsefeil som (bare) kan behandles ved å sende kall til erstatningsmetodene som nå er plassert i org.eclipse.ui.ide.IDE.
Dette er de aktuelle IWorkbenchPage-metodene: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) og openSystemEditor(IFile).