Az Eclipse inkompatibilis módon változott a 3.1 és 3.2 verzió között, és ez hatással van a bedolgozókra. Az alábbi bejegyzések leírják a módosított területeket, és útmutatást biztosítanak az 3.1 verziószámú bedolgozók átállításához 3.2 verzióra. Ezeket csak akkor kell megtekintenie, ha problémája van a 3.1 verziószámú bedolgozó futtatásával a 3.2 verzión.
Befolyásolt elem:Az IWorkspace
API
ügyfelei, amely feltételezik, a helyi fájlrendszer erőforrásokat tárol.
Leírás:
Az Eclipse 3.2 változat előtt minden meglévő IResource
rendelkezett egy megfelelő fájllal
vagy könyvtárral a fájlrendszerben, amelyet a java.io.File
el tud érni. Az
Eclipse 3.2 változatban olyan erőforrások létrehozása támogatott, amelyek tartalmát egy tetszőleges
mentési fájlrendszer tárolja. Ezen támogatást használó erőforrások már nem ábrázolhatók közvetlenül
java.io.File fájlként.
Szükséges tevékenység: A régi IResource.getLocation() metódus az erőforrás helyi fájlrendszer elérési útját adja meg. Ez a metódus nullértéket ad vissza nem a helyi fájlrendszeren tárolt erőforrások esetén. A getLocation() legtöbb hívója ezt tette a java.io.File példány lekérése érdekében, amely nem a helyi fájlrendszeren tárolt erőforrások esetén nem használható.
Az új org.eclipse.core.filesystem bedolgozó egy általános fájlrendszer alkalmazás programozási felületet biztosít, amely a java.io.File helyett használható. Az org.eclipse.core.filesystem.IFileStore egy példánya nagyjából ugyanazokat a metódusokat biztosítja, mint amelyeket a java.io.File. A következő kódrészlet az IFileStore egy példányát kérdezi le egy adott erőforráshoz:
IResource resource = ...;//néhány erőforrás IFileStore store = EFS.getStore(resource.getLocationURI());
A következő tábla egyenértékű metódusokat biztosít az IFileStore-on az általában java.io.File segítségével végzett műveletekhez:
java.io.File | IFileStore |
---|---|
törlés | törlés |
getName | getName |
getParent | getParent |
list | childNames |
mkdir | mkdir(EFS.SHALLOW, null) |
mkdirs | mkdir(EFS.NONE, null) |
renameTo | áthelyezés |
new FileInputStream(file) | openInputStream |
new FileOutputStream(file) | openOutputStream |
Az IFileStore alkalmazás programozási felületen a fájlokkal kapcsolatos információk nagy része egy IFileInfo nevű struktúrában kerül tárolásra, amely az IFileStore.fetchInfo() meghívásával kérdezhető le. Ez a kialakítás a kód jobb optimalizálást teszi lehetővé a java.io.File használatával, mivel a fájllal kapcsolatos számos jellemző gyakran egy fájlrendszerhívással lekérdezhető. Ne feledje el, hogy az IFileInfo információi elavulttá válnak, ha az alapul szolgáló fájl változik, így a példányokat csak addig kell tárolni, amíg szükség van rájuk. Az alábbiakban látható néhány java.io.File metódus, amelyeknek létezik IFileInfo megfelelője:
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) |
Konkrét példa: a kód, amely korábban a java.io.File.exists() metódust hívta meg, most az IFileStore.fetchInfo().exists() metódust hívja. Ha az IFileInfo módosítva lett, akkor az eredményt el kell tárolni az IFileStore.putInfo metódusban. Ez a részlet például a fájl csak olvasható attribútumát ábrázolja
IFileStore store = ...;//egy fájltároló 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);
A getLocation() metódushoz hasonlóan, a projektleírás helye már nem a helyi fájlrendszeren található. Az IProjectDescription.getLocationURI() metódus segítségével lekérdezhető az erőforrás helye egy tetszőleges fájlrendszeren.
Néhány ügyfélnek feltétlenül rendelkeznie kell a fájl helyi ábrázolásával. Például elindíthatnak egy natív eszközt a fájlon, vagy használhatnak nem Eclipse-re felkészített könyvtárakat, amelyeket csak a fájlrendszer-erőforrásokat tudják kezelni (mint például a java.util.zip.ZipFile). Ilyen esetekben megkérhet egy IFileStore-t, hogy visszaadja a tartalom ideiglenesen tárolt helyi példányát:
IFileStore store = ...;//egy fájltároló //akkor látható, ha közvetlenül ábrázolható helyi fájlként java.io.File local = store.toLocalFile(EFS.NONE, null); //ha nem, akkor kérje a fájlról egy ideiglenesen tárolt helyi példányt if (local == null) local = store.toLocalFile(EFS.CACHE, null);
Ne feledje el, hogy a fájl ideiglenesen tárolt példányának lekérése után nem marad szinkronban az aktuális fájlrendszerrel, amelyről származott. Az ideiglenesen tárolt példány módosításakor az alapul szolgáló fájl nem változik.
Az ügyfelek, amelyek nem tudják kezelni a helyi fájlrendszeren kívül lévő erőforrásokat, elképzelhető, hogy továbbra is adaptálni kívánják a kódjukat a könnyebben helyreállítható hiba érdekében. Az ügyfelek ellenőrizhetik, hogy az erőforrás a helyi fájlrendszeren található-e, és figyelmen kívül hagyhatják az erőforrást vagy riasztáshatják a felhasználót, ha olyan erőforrást találnak, amelyet nem tudnak kezelni. Annak megállapításához, hogy az erőforrás a helyi fájlrendszeren van-e, ki meg kell ismerni a fájlrendszer sémát. Ez az erőforrásról kérdezhető le a a következő módon:
IResource resource = ...;//néhány erőforrás URI uri = resource.getLocationURI(); if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) { //a fájl a helyi fájlrendszeren található } else { //a fájl nem a helyi fájlrendszeren található }
Ha van kéznél egy IFileStore példány, akkor a séma a a következőképp kérdezhető le:
IFileStore store = ...;//fájltároló store.getFileSystem().getScheme();
Befolyásolt elem: A
MultiPageEditorSite.progressStart()
vagy
MultiPageEditorSite.progressEnd()
metódust meghívó ügyfelek.
Leírás: Az Eclipse 3.0 fejlesztése során ezek a metódusok hozzáadásra kerültek a folyamattámogatási feladat részeként. A 3.0 változat előtt a folyamat kezelési módszere változott, és ez a metódus már nem szükséges. Programozóhiba miatt ezek a nyilvános metódusok megmaradtak a 3.0 kiadásban. Ez a két metódus semmilyen funkciót nem szolgáltatott az Eclipse kiadásban, így törlésre került.
Szükséges tevékenység: A MultiPageEditorSite.progressStart()
vagy MultiPageEditorSite.progressEnd()
metódust meghívó ügyfeleknek át kell térniük az
IWorkbenchSiteProgressService
használatára.
Befolyásolt elem: Egyéni config.ini fájllal rendelkező ügyfelek, akik alkalmazásaikat a 3.2 alá helyezik át.
Leírás: A 3.2 előtt a config.ini fájlban az
osgi.bundles tipikus értéke org.eclipse.core.runtime@2:start,
org.eclipse.update.configurator@3:start
volt. A
futási környezet átdolgozása
miatt, az értéket az alkalmazás sikeres indításához frissíteni szükséges.
Szükséges tevékenység: Módosítsa az osgi.bundles
értékét, hogy az org.eclipse.equinox.common@2:start,
org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start
értéket tartalmazza.
Befolyásolt elem: RCP alkalmazásokat telepítő ügyfelek, amelyek értéket adtak az osgi.bundles tulajdonságnak.
Leírás: A 3.2 előtt a fő jnlp fájlban az osgi.bundles
tipikus értéke org.eclipse.core.runtime@2:start,
org.eclipse.update.configurator@3:start
volt. A
futási környezet átdolgozása
miatt, az értéket frissíteni kell, különben előfordulhat, hogy
NullPointerException
történik és az alkalmazás nem indul el.
Szükséges tevékenység: Módosítsa az osgi.bundles
értékét, hogy az org.eclipse.equinox.common@2:start,
org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start
értéket tartalmazza.
Befolyásolt elem: A Bundle.start()
metódust meghívó ügyfelek.
Leírás: Az Eclipse termékben a kötegeket késleltetett
indítású kötegként az Eclipse-LazyStart
fejléc (vagy az
elavult Eclipse-AutoStart
fejléc) segítségével jelölhető meg.
Az Eclipse 3.1 változatában az
org.osgi.framework.Bundle.start()
metódus a késleltetett
indítású kötegeket nem jelölte állandó indításúként. Mivel a késleltetett
indítású kötegeket a rendszer sosem jelölte meg állandó indításúként, ezek
nem kerültek automatikusan indításra az Eclipse újraindításakor. A
Bundle.start()
javadoc a metódus hívásakor a következőnek
kell történnie:
"Állandóan rögzíthető, hogy a köteg indításra került. A Keretrendszer újraindításakor a köteget automatikusan el kell indítani."
Az Eclipse 3.2 változatában a Bundle.start()
metódus
javításának köszönhetően a köteget megfelelően állandó indításúnak jelöli
meg, még akkor is, ha a köteg késleltetett indítású köteg. A javítást az
OSGi keretrendszer-specifikáció tette szükségessé. Ennek eredményeként a
Bundle.start()
hívói a köteget indításra kényszerítik az
Eclipse újraindításakor. Általánosságban ez kerülendő gyakorlatnak
minősül, hiszen szükségtelen kötegek kerülnek aktiválásra az Eclipse
indításakor. Bizonyos esetekben ez nem várt eredményekkel járhat, például
a 134412
számú hiba esetében.
Szükséges tevékenység: A Bundle.start()
ügyfeleinek mérlegelniük kell, hogy kívánják-e a köteget minden
újraindításkor állandóan aktiválni a köteget. Ha ez nem célja az
ügyfélnek, akkor más módszert kell találniuk a köteg aktiválásához. A
legtöbb esetben a Bundle.start()
hívások elkerülhetők, ha
egyszerűen a célkötegnek lehetővé teszik a késleltetett aktiválást, amikor
onnan osztályok kerülnek betöltésre. Léteznek olyan ritka esetek, amelyek
szükségessé tehetik egy késleltetett indítású köteg agresszív aktiválását,
de ez nem jelenti a kötegek állandó megjelölését újraindításkor
aktiválódóként. Ezekben a szituációkban a Bundle.loadClass()
segítségével lehet a köteg aktiválni kívánt osztályát betölteni a
Bundle.start()
hívása helyett.
Az Eclipse 3.0 rendszer nem támogatta az aláhúzás ('_') karakter
használatát a verziószám-azonosító minősítő szegmensében, de ugyanakkor
ezt a rendszer nem is tartatta be. Ha egy bedolgozó verziószám-azonosító
minősítője aláhúzást tartalmazott, akkor a bedolgozó fájlrendszerre
exportálásakor, illetve a bedolgozó frissítési helyről telepítésekor a
karaktert a rendszer kötőjelre ('-') cserélte.
Az Eclipse 3.1 változatában a minősítőkben szereplő karakterekre vonatkozó
szabályokat enyhítettük, tehát a minősítők tartalmazhatnak aláhúzást.
Ennek köszönhetően az eredeti szabályt sértő bedolgozó exportálásakor és
telepítésekor megmaradt a minősítő eredeti állapota. Ez az apró módosítás
véletlenül kimaradt a 3.0 változatról a 3.1 változatra való áttéréshez
tartozó útmutatóból. A történet folytatása (és ez igaz az Eclipse 3.2
változatára is), hogy a továbbiakban is fenntartjuk a kompatibilitást az
Eclipse 3.1 változatával, és a verziószámukban aláhúzás karaktert
tartalmazó bedolgozóknak tanácsos tekintetbe venni a fent említett
módosításokat a régi bedolgozó-változatok kezelésekor (mind exportáláskor,
mind pedig akkor, ha frissítési helyen találhatók). Vagyis például az
olyan bedolgozó-szolgáltatóknak, amelyek egy telepítési helyen a bedolgozó
régi változatát tartják, meg kell győződniük róla, hogy a fájlrendszerben
tárolt név megegyezik a bedolgozó nevével.