Eclipse har ändrats på ett inkompatibelt sätt mellan version 3.1 och 3.2 på ett sätt som påverkar insticksprogram. Under följande rubriker beskrivs de olika områdena som har ändrats. Här finns även instruktioner för hur du migrerar 3.1-insticksprogram till version 3.2. Du behöver endast läsa detta om det har uppstått problem när du ska köra 3.1-insticksprogrammet i version 3.2.
Vad påverkas:Klienter till IWorkspace
-API:t som antar att resurser lagras i det lokala filsystemet.
Beskrivning:
Före Eclipse 3.2 hade varje befintlig IResource
en motsvarande fil eller katalog i ett filsystem som kunde öppnas via java.io.File
. I Eclipse 3.2 har funktioner för att skapa resurser vars innehåll lagras i ett säkerhetskopieringsfilsystem lagts till. Resurser som använder de här funktionerna kan inte längre visas direkt som en java.io.File.
Åtgärd som krävs: Den gamla metoden IResource.getLocation() returnerar sökvägen i det lokala filsystemet för en resurs. Den här metoden returnerar null för resurser som inte lagras i det lokala filsystemet. De flesta som anropade getLocation() gjorde det för att erhålla en förekomst av java.io.File som inte längre kan användas för resurser som inte lagras i det lokala filsystemet.
Det nya insticksprogrammet org.eclipse.core.filesystem tillhandahåller ett generisk filsystem-API som kan användas i stället för java.io.File. En förekomst av org.eclipse.core.filesystem.IFileStore tillhandahåller de flesta av de metoder som är tillgängliga i java.io.File. Följande kodstycke erhåller en förekomst av IFileStore för en viss resurs:
IResource resource = ...;//en resurs IFileStore store = EFS.getStore(resource.getLocationURI());
I följande tabell finns motsvarande metoder i IFileStore för åtgärder som vanligen utförs 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(file) | openInputStream |
new FileOutputStream(file) | openOutputStream |
I IFileStore-API:t lagras det mesta av informationen om en fil i en struktur med namnet IFileInfo som hämtas genom anrop till IFileStore.fetchInfo(). Med den här designen ökas möjligheten att optimera kod med hjälp av java.io.File eftersom många attribut för en fil ofta kan hämtas med ett enda filsystemsanrop. Lägg märke till att informationen i en IFileInfo-struktur blir inaktuell om den underliggande filen ändras, så förekomster bör inte behållas när de inte behövs längre. Här följer några metoder i java.io.File som har motsvarande metoder i 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 ett konkret exempel kan kod som tidigare anropade java.io.File.exists() nu anropa IFileStore.fetchInfo().exists(). När ett IFileInfo ändras måste resultatet lagras med hjälp av metoden IFileStore.putInfo. Exempel: Det här kodstycket ändrar skrivskyddsattributet för en fil
IFileStore store = ...;//ett 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);
Precis som med metoden getLocation() kan det hända att platsen för projektbeskrivningen inte längre finns i det lokala filsystemet. Metoden IProjectDescription.getLocationURI() kan användas till att hämta platsen för en resurs i ett slumpmässigt valt filsystem.
Vissa klienter måste absolut ha en lokal version av filen. De kan till exempel starta ett internt verktyg mot filen eller använda bibliotek utan Eclipse-funktioner och endast kan hantera filsystemsresurser (till exempel java.util.zip.ZipFile). I de här fallen kan du ställa en fråga i IFileStore så returneras en cachelagrad lokal kopia av innehållet:
IFileStore store = ...;//ett fillager //kontrollera om det kan återges direkt som en lokal fil java.io.File local = store.toLocalFile(EFS.NONE, null); //i annat fall frågar du efter en cachelagrad lokal kopia av filen if (local == null) local = store.toLocalFile(EFS.CACHE, null);
Lägg märke till att när du väl har erhållit en kopia av filen kommer den inte att fortsätta vara synkroniserad med det filsystem den hämtades från. Om du ändrar den cachelagrade kopian ändras inte den underliggande filen.
Det kan hända att klienter som inte kan hantera resurser utanför det lokala filsystemet ändå vill anpassa kod så att den misslyckas på ett elegantare sätt. Klienter kan kontrollera om en resurs finns i det lokala filsystemet och antingen ignorera resursen eller varna användaren när en resurs påträffas som inte kan hanteras. Om du vill ta reda på om en resurs finns i det lokala filsystemet måste du ta reda på filsystemsschemat för den. Du kan hämta det från en resurs på följande sätt:
IResource resource = ...;//en resurs URI uri = resource.getLocationURI(); if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) { //filen finns i det lokala filsystemet } else { //filen finns inte i det lokala filsystemet }
Om du har en förekomst av IFileStore till hands kan du hämta schemat på följande sätt:
IFileStore store = ...;//ett fillager store.getFileSystem().getScheme();
Vad påverkas: Klienter som anropar MultiPageEditorSite.progressStart()
eller MultiPageEditorSite.progressEnd()
.
Beskrivning: Under utvecklingen av Eclipse 3.0 lades de här metoderna till som en del av arbetet med förloppsfunktionerna. Före version 3.0 ändrades det sätt som förlopp hanterades på och den här metoden behövdes inte längre. På grund av ett programmeringsfel lämnades de här publika metoderna i version 3.0. De här två metoderna har inte haft någon funktion i någon Eclipse-version och har nu tagits bort.
Åtgärd som krävs: Klienter som anropar MultiPageEditorSite.progressStart()
eller
MultiPageEditorSite.progressEnd()
bör använda IWorkbenchSiteProgressService
i stället.
Vad påverkas: Klienter som har en anpassad config.ini och flyttar tillämpningen till 3.2.
Beskrivning: Före 3.2 var det vanliga värdet för osgi.bundles som ingick i config.ini org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
På grund av körtidsomfaktorisering måste det här värdet uppdateras för att tillämpningen ska starta som den ska.
Åtgärd som krävs:Ändra värdet för osgi.bundles så att org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start.
ingår.
Vad påverkas: Klienter som utplacerat RCP-tillämpningar och angett ett värde för osgi.bundles.
Beskrivning: Före 3.2 var det vanliga värdet för osgi.bundles som ingick i huvud-jnlp-filen org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
På grund av körtidsomfaktorisering måste det här värdet uppdateras. I annat fall kan NullPointerException
-undantag inträffa som förhindrar tillämpningen från att starta.
Åtgärd som krävs:Ändra värdet för osgi.bundles så att org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start.
ingår.
Vad påverkas: Klienter som anropar Bundle.start()
.
Beskrivning:
I Eclipse anges att ett samlingspaket startas automatiskt med hjälp av Eclipse-LazyStart
-huvudet (eller det inaktuella Eclipse-AutoStart
huvudet). I Eclipse 3.1 markerade inte metoden org.osgi.framework.Bundle.start()
samlingspaket med automatisk start som ständigt startade. Eftersom samlingspaket med automatisk start aldrig markerades som permanent startade startades de inte automatiskt när Eclipse startades om. I javadoc för Bundle.start()
anges att följande måste inträffa när metoden anropas:
"Registrera permanent att samlingspaketet har startats. När ramverket har startats om måste samlingspaketet startas automatiskt."
I Eclipse 3.2 har metoden Bundle.start()
korrigerats så att samlingspaketet har markerats som permanent startat även om samlingspaketet är ett samlingspaket med automatisk start. Den här korrigeringen var nödvändig för kompatibilitet med specifikationen för OSGi-ramverket. Det innebär att den som anropar Bundle.start()
tvingar samlingspaketet att startas när Eclipse startas om.
I allmänhet anses det här vara dålig praxis eftersom det innebär att onödiga samlingspaket aktiveras varje gång Eclipse startas. I vissa fall kan det orsaka oväntade resultat, till exempel fel 134412.
Åtgärd som krävs: Klienter till Bundle.start()
bör fråga sig om de vill aktivera samlingspaketet permanent vid varje omstart. Om det inte är avsikten bör klienterna aktivera samlingspaketet på något annat sätt. I de flesta fall kan anrop av Bundle.start()
undvikas genom att helt enkelt tillåta att målsamlingspaketet aktiveras automatiskt när klasser läses in från det. I sällsynta fall är det nödvändigt att aktivera samlingspaket med automatisk start aktivt, men inte markera dem permanent för aktivering vid omstart. I sådana fall bör Bundle.loadClass()
användas till att läsa in en klass från det samlingspaket som måste aktiveras i stället för att Bundle.start()
anropas.
I Eclipse 3.0 gick det inte att använda ett understreck ('_') i namnledet för ett versions-ID men det var heller inte tvingande. Om ett versions-ID för ett insticksprogram innehöll ett understreck i namnledet omvandlades understrecket till ett bindestreck ('-') när insticksprogrammet exporterades till filsystemet och även när insticksprogrammet installerades från en uppdateringswebbplats.
I Eclipse 3.1 blev reglerna för vilka tecken som tillåts i namnled friare och understrecket kunde nu användas, så när ett felaktigt insticksprogram exporterades eller installerades ändrades inte namnledet.
Den här subtila ändringen utelämnades av misstag i migreringshandboken för 3.0 till 3.1.
I framtiden (och för Eclipse 3.2) behåller vi kompatibiliteten med Eclipse 3.1
och användare av insticksprogram där understreck används i versionsnamnleden bör vara medvetna om de ovan nämnda ändringarna när de hanterar äldre versioner av insticksprogrammet (både vid export och när de finns på uppdateringswebbplatser). Det här innebär till exempel att insticksprogramsleverantörer som har gamla versioner av sitt insticksprogram på en uppdateringswebbplats bör kontrollera att namnet i filsystemet överensstämmer med namnet på insticksprogrammet.