Eclipse ble endret slik at det oppstod inkompatibiliteter mellom 3.1 og 3.2 på måter som påvirker plugin-moduler. De følgende punktene beskriver områdene som ble endret, og de inneholder instruksjoner for migrering av plugin-moduler fra 3.1 til 3.2. Du trenger bare å se her hvis du har problemer med å kjøre plugin-moduler fra 3.1 på 3.2.
Dette påvirkes: Klienter i APIet IWorkspace
som antar at ressurser er lagret i det lokale
filsystemet.
Beskrivelse:
Før Eclipse 3.2 hadde hver eksisterende IResource
en tilsvarende fil eller katalog i filsystemet som
java.io.File
hadde tilgang til. I Eclipse 3.2 ble det lagt til støtte for å opprette ressurser hvis innhold lagres i et vilkårlig reservefilsystem. Ressurser som bruker denne støtten, kan ikke lenger fremstilles direkte som en java.io.File.
Nødvendig handling: den gamle metoden IResource.getLocation() returnerer den lokale filsystembanen til en ressurs. Denne metoden returnerer null for ressurser som ikke er lagret i det lokale filsystemet. De fleste som kaller opp getLocation(), gjør det for å få tak i en forekomst av java.io.File, som ikke langer kan brukes for ressurser som ikke er lagret i det lokale filsystemet.
Den nye plugin-modulen org.eclipse.core.filesystem har et API for generisk filsystem som kan brukes i stedet for java.io.File. Særlig inneholder en forekomst av org.eclipse.core.filesystem.IFileStore de fleste av de samme metodene som er tilgjengelige i java.io.File. Følgende kodesnutt henter en forekomst av IFileStore for en gitt ressurs:
IResource resource = ...;//en ressurs IFileStore store = EFS.getStore(resource.getLocationURI());
Følgende tabell sørger for tilsvarende metoder i IFileStore for operasjoner som vanligvis utføres med java.io.File:
java.io.File | IFileStore |
---|---|
delete | delete |
getName | getName |
getParent | getParent |
list | childNames |
mkdir | mkdir(EFS.SHALLOW, null) |
mkdirs | mkdir(EFS.NONE, null) |
renameTo | move |
new FileInputStream(fil) | openInputStream |
new FileOutputStream(fil) | openOutputStream |
I APIet IFileStore lagres det meste av informasjonen om en fil i en struktur kalt IFileInfo, som du får tak i ved å kalle opp IFileStore.fetchInfo(). Denne utformingen gir bedre muligheter for optimalisering enn kode som bruker java.io.File, for det er ofte mulig å hente mange attributter for en fil med ett enkelt filsystemkall. Merk at informasjonen i en IFileInfo blir foreldet hvis den underliggende filen endres, så forekomster bør beholdes bare så lenge det er nødvendig. Her er noen metoder for java.io.File som har tilsvarende metoder for IFileInfo:
java.io.File | IFileInfo |
---|---|
canWrite | isReadOnly |
exists | exists |
getName | getName |
isDirectory | isDirectory |
isFile | !isDirectory() |
isHidden | isHidden |
lastModified | getLastModified |
length | getLength |
setLastModified | setLastModified |
setReadOnly | setAttribute(EFS.ATTRIBUTE_READ_ONLY, true) |
Som et konkret eksempel kan kode som tidligere kalte opp java.io.File.exists(), nå kalle opp IFileStore.fetchInfo().exists(). Når en IFileInfo endres, må resultatet lagres tilbake ved hjelp av metoden IFileStore.putInfo. Denne snutten vender for eksempel leseattributt for en fil:
IFileStore store = ...;//et fillager IFileInfo info = store.fetchInfo(); boolean readOnly = info.getAttribute(EFS.ATTRIBUTE_READ_ONLY); info.setAttribute(EFS.ATTRIBUTE_READ_ONLY, !readOnly); store.putInfo(info, EFS.SET_ATTRIBUTES, null);
Som for metoden getLocation() kan prosjektbeskrivelsen plassering ikke lenger være i det lokale filsystemet. Metoden IProjectDescription.getLocationURI() kan brukes til å hente plassering for en ressurs i et vilkårlig filsystem.
Noen klienter må absolutt ha en lokal fremstilling av en fil. For eksempel kan de starte et internt verktøy mot filen, eller de kan bruk biblioteker som ikke kjenner Eclipse, og som bare kan håndtere filsystemressurser (f.eks. java.util.zip.ZipFile). I slike tilfeller kan du be en IFileStore returnere en hurtigbufret kopi av sitt innhold:
IFileStore store = ...;//et fillager //se om det kan fremstilles direkte som en lokal fil java.io.File local = store.toLocalFile(EFS.NONE, null); //hvis ikke, ber du om en hurtigbufret lokal kopi av filen if (local == null) local = store.toLocalFile(EFS.CACHE, null);
Merk at når en hurtigbufret kopi av en fil hentes, er den ikke lenger synkronisert med det faktiske filsystemet den kom fra. Endring av den hurtigbufrede versjonen vil ikke endre den underliggende filen.
Klienter som ikke kan håndtere ressurser utenfor det lokale filsystemet, kan likevel tilpasse sin kode, slik at feilen kan kontrolleres bedre. Klienter kan kontrollere om en ressurs finnes i det lokale filsystemet, og enten ignorere resultatet eller varsle brukeren når de finner en ressurs de ikke kan håndtere. For å bestemme om en ressurs finnes i det lokale filsystemet, må du finne skjema for filsystemet. Det kan du hente fra en ressurs slik:
IResource resource = ...;//en ressurs URI uri = resource.getLocationURI(); if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) { //filen er i det lokale filsystemet } else { //filen er ikke i det lokale filsystemet }
Hvis du har en IFileStore-forekomst, kan du hente skjemaet slik:
IFileStore store = ...;//et fillager store.getFileSystem().getScheme();
Dette påvirkes: Klienter som kaller opp MultiPageEditorSite.progressStart()
or MultiPageEditorSite.progressEnd()
.
Beskrivelse: Under utviklingen av Eclipse 3.0 ble disse metodene lagt til som en del av fremdriftsstøttearbeidet. Før 3.0 ble måten fremdriften ble behandlet på, endret, og denne metoden var ikke lenger nødvendig. Disse fellesmetodene ble ved en programmeringsfeil beholdt for 3.0-utgaven. Disse to metodene har aldri hatt noen funksjon i en Eclipse-utgave, og er nå slettet.
Nødvendig handling: Klienter som kaller opp
MultiPageEditorSite.progressStart()
eller
MultiPageEditorSite.progressEnd()
, må bruke IWorkbenchSiteProgressService
i stedet.
Dette påvirkes: Klienter som har en tilpasset config.ini og flytter sin applikasjon til 3.2.
Beskrivelse: Før 3.2 var den typiske verdien for osgi.bundles i config.ini org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
På grunn av refaktorisering ved kjøretid må denne verdien oppdateres for at applikasjonen
skal starte.
Nødvendig handling:Endre verdien for osgi.bundles så den inkluderer
org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start.
Dette påvirkes: Klienter som distribuerer RCP-applikasjoner og har spesifisert en verdi for osgi.bundles.
Beskrivelse: Før 3.2 var den typiske verdien for osgi.bundles i hoved-JNLP-filen org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
På grunn av refaktorisering ved kjøretid må denne verdien oppdateres. Ellers kan NullPointerException
bli kastet og hindre applikasjonen i å starte.
Nødvendig handling:Endre verdien for osgi.bundles så den inkluderer
org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start.
Dette påvirkes: Klienter som kaller opp Bundle.start()
.
Beskrivelse: I Eclipse spesifiseres en bunt som en langsomtstartende bunt
ved hjelp av toppteksten Eclipse-LazyStart
(eller den foreldede toppteksten Eclipse-AutoStart
).
I Eclipse 3.1 markerte ikke metoden org.osgi.framework.Bundle.start()
langsomtstartende bunter som permanent stertet.
Siden langsomtstartende bunter aldri ble merket som permant startede bunter, ble de ikke automatisk startet når Eclipse ble startet på nytt.
Javadoc for Bundle.start()
fastslår at følgende må skje når metoden kalles:
"Registrer permanent at denne bunten er startet. Når rammen startes på nytt, må denne bunten startes automatisk."
I Eclipse 3.2 er metoden Bundle.start()
festet for å merke bunten som permanent startet selv om bunten er en langsomtstartende bunt.
Denne rettelsen var nødvendig for å etterkomme OSGi-rammespesifikasjonen. Dermed vil
oppkalling av Bundle.start()
tvinge bunten til å startes når
Eclipse startes på nytt.Generelt anses dette som dårlig vane, for det vil gjøre at bunter blir unødvendig aktivert
hver gang Eclipse startes.
I noen tilfeller kan det gi uventede resultater som f.eks.
programfeil 134412.
Nødvendig handling: Klienter av
Bundle.start()
må vurdere om de har som mål å permanent aktivere bunten for hver omstart.
Hvis det ikke det hensikten, bør klientene finne en annen måte å aktivere bunten på.
I de fleste tilfeller kan kall til Bundle.start()
unngås enkelt ved at målbunten aktiveres langsomt når klassene lastes fra dem.
Det er noen sjeldne tilfeller der en langsomtstartende bunt må aktiveres aggressivt, men ikke permanent merkes for aktivering ved omstart.
I disse tilfellene bør det brukes Bundle.loadClass()
for å laste inn en klasse fra bunten som må aktiveres, i stedet for at
Bundle.start()
kalles opp.
I Eclipse 3.0 ble bruk at et understrekingstegn ('_') i kvalifikatorsegmentet til en versjons-ID ikke støttet, men dette ble heller ikke tvunget igjennom.
Hvis en plugin-versjons-ID innholdt en understreking i kvalifikatoren, ble dette tegnet omdannet til en bindestrek
('-') ved eksport av plugin-modelen til filsystemet og også ved installering av plugin-modulen fra et oppdateringssted.
I Eclipse 3.1 ble reglene for tegn som var tillatt i kvalifikatorer, lempet på så de inkluderte understrekingstegnet,
så når en plugin-modul med dette ble eksportert eller installert, ble ikke kvalifikatoren endre i forhold til det opprinnelige.
Denne lille endringen ble ved et uhell utelatt fra veiledningen for migrering fra 3.0 til 3.1.
Videre (og for Eclipse 3.2) vedlikeholder vi kompatibiliteten med Eclipse 3.1, og plugin-moduler som bruker
understrekingstegn i sine versjonskvalifikatorer, bør være klar over de nevnte endringene når de har å gjøre med gamle plugin-versjoner.
Det betyr for eksempel at plugin-leverandører som har gamle versjoner av sin plugin-modul på et oppdateringssted, bør sørge for at
navnet i filsystemet samsvarer med navnet på plugin-modulene.