Eclipse 3.0-plugin-overførsel - ofte stillede spørgsmål

Hvorfor er Eclipse API ændret, så der ikke er kompatibilitet mellem 2.1 og 3.0?

Eclipse 3.0 er en udvikling af Eclipse 2.1. Der var nogle få områder, hvor vi ikke kunne udvikle Eclipse, samtidig med at vi beholdt en fuldstændig kompatibilitet mellem udgaverne. De fire primære årsager til inkompatibilitet er:

Oversigt over bestemte inkompatibiliteter.

Fungerer en 2.1-plugin i Eclipse 3.0?

Ja, bortset fra nogle få tilfælde. Hvis en plugin kun baserer sig på 2.1 API'er, fungerer den fortsat i 3.0. De ganske få undtagelser er steder i API'et, hvor ændringerne mellem 2.1 og 3.0 ikke kunne foretages kompatibelt. Hvis en plugin bruger en af disse, fungerer den ikke.

Min 2.1-plugin benytter klasser i interne pakker. Fungerer den også i Eclipse 3.0?

Hvis en plugin baserer sig på interne klasser eller på funktionsmåder, der ikke er angivet i Eclipse 2.1 API, er det umuligt at sige noget generelt om, hvorvidt plugin'en virker i 3.0. Du bliver nødt til at prøve dig frem.

Hvordan udfører jeg min plugin i Eclipse 3.0 uden at røre den?

Installér 2.1-plugin'en i underbiblioteket eclipse/plugins/ i et Eclipse 3.0-baseret produkt, og genstart Eclipse. Eclipse genkender plugin'en som en ikke-konverteret 2.1-plugin (ved hjælp af header'en i plugin.xml) og foretager automatisk justeringer for at kompensere for ændringer i Platform-plugin-afhængighederne og omdøbte Platform-udvidelsespunkter.

Skal 2.1-plugins ændres for at kompilere korrekt i Eclipse 3.0?

Ja, altid. Der er visse forskelle mellem Eclipse 2.1 og 3.0, som gør det nødvendigt med ændringer i alle plugins, efterhånden som de bliver taget i brug. Hvis du har en plugin, der er skrevet til 2.1, og du vil kompilere den igen, skal den overføres til 3.0, før den kan udvikles videre til 3.0.

Hvordan overfører jeg min plugin til Eclipse 3.0?

Når du har indlæst (eller importeret) dit plugin-projekt i et Eclipse 3.0-arbejdsområde, skal du bruge PDE-værktøjer > Overfør til 3.0 (projektets kontekstmenu) til at konvertere plugin'ens manifest til 3.0-format og automatisk tilpasse listen med krævede platforms-plugins og referencer til platformsudvidelsespunkter, som er blevet omdøbt. I de fleste tilfælde kompileres og udføres koden for plugin'en derefter. Koden for plugin'en skal derefter gennemgås for at sikre, at den ikke er afhængig af et af områderne med en inkompatibel API-ændring.

Kan jeg være sikker på, at en plugin har kompileringsfejl og -advarsler, hvis den baserer sig på API, som er ændret, så den ikke er kompatibel?

Nej. Nogle områder af en ikke-kompatibel ændring markeres ikke af Java-compileren.

Kan jeg bare ignorere advarsler i koden, som stammer fra brugen af forældede API'er?

Ja, på kort sigt kan du godt. Når det er muligt, markeres forældede API'er som forældede i stedet for blot at blive slettet og fortsat fungere (selvom det kun var muligt i begrænsede tilfælde). Det haster normalt ikke med at fjerne forældede API'er, men den kendsgerning, at de nu er forældede, betyder, at der er en bedre måde at gøre tingene på. Plugins skal vænnes fra at bruge forældede API'er hurtigst muligt.

Når jeg overfører min plugin til Eclipse 3.0, kan jeg så stadig installere og udføre den deraf følgende binære plugin i Eclipse 2.1?

Nej. Den understøttes ikke, og den ville sandsynlig ikke fungere på grund af de omdøbte udvidelsespunkter.

Hvad er formålet med org.eclipse.core.runtime.compatibility?

Skiftet i 3.0 til en OSGi-baseret runtime har gjort nogle af de eksisterende centrale runtime-API'er forældede. Hvor det var muligt, er forældede API'er i pakkerne org.eclipse.core.runtime.* - sammen med den bagvedliggende implementering - flyttet fra plugin'en org.eclipse.core.runtime til en ny plugin kaldet org.eclipse.core.runtime.compatibility. Som standard er nyligt oprettede plugins afhængige af org.eclipse.core.runtime, og det forventes, at de kun benytter ikke-forældede runtime-API'er. På den anden side afhænger eksisterende plugins, der overføres fra 2.1 som standard af org.eclipse.core.runtime.compatibility og kan også benytte de gamle API'er (plugin'en org.eclipse.core.runtime.compatibility reeksporterer API'er fra org.eclipse.core.runtime). Plugin'en org.eclipse.core.runtime.compatibility inkluderes sandsynligvis i Eclipse IDE-konfigurationerne, men ikke i produkter baseret på RCP-konfigurationer.

Hvad er formålet med org.eclipse.ui.workbench.compatibility?

org.eclipse.ui.workbench.compatibility er et plugin-fragment, som giver udvidet binær kompatibilitet til 2.1-plugins, der udføres i et produkt baseret på Eclipse 3.0. I 3.0 er seks metoder med en eksplicit afhængighed af IFile eller IMarker flyttet fra org.eclipse.ui.IWorkbenchPage-grænsefladen for helt klart at adskille arbejdsbænken fra arbejdsområdet og ressourcer. Org.eclipse.ui.workbench.compatibility-fragmentet sørger for, at disse metoder kan tilføjes igen, så eksisterende 2.1-plugins kan udføres uden at skulle ændres. Bemærk dog, at plugins, der overføres til 3.0, og som henviser til de flyttede metoder, oplever kompileringsfejl, som (kun) kan løses ved at kalde de erstatningsmetoder, der nu er placeret i org.eclipse.ui.ide.IDE.

De IWorkbenchPage-metoder, det drejer sig om, er: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) og openSystemEditor(IFile).