Eclipse on muuttunut 3.1- ja 3.2-versioiden välillä yhteensopimattomilla tavoilla, jotka vaikuttavat lisäosiin. Seuraavat määritykset kuvaavat muuttuneita alueita. Lisäksi niissä on ohjeita 3.1-lisäosien siirtämisestä 3.2-versioon. Huomaa, että näitä tietoja tarvitsee tutkia vain, jos 3.1-lisäosan ajossa 3.2-versiossa ilmenee ongelmia.
Mitä muutos koskee: IWorkspace
-sovellusohjelmaliittymän työasemia,
jotka olettavat, että resurssit on tallennettu paikalliseen tiedostojärjestelmään.
Kuvaus:
Ennen Eclipsen versiota 3.2 kullakin IResource
-kohteella oli vastaava tiedosto tai hakemisto tiedostojärjestelmässä, jossa niitä voitiin käyttää kohteen java.io.File
avulla. Eclipsen versiossa 3.2 lisättiin tuki sellaisten resurssien luontiin, joiden sisältö on tallennettu johonkin muuhun tiedostojärjestelmään. Tätä tukea käyttäviä resursseja ei enää voi kuvata suoraan java.io.File-kohteina.
Tarvittavat toimet: Vanha metodi IResource.getLocation() palauttaa resurssien paikallisen tiedoston järjestelmäpolun. Tämä metodi palauttaa tyhjäarvon resursseille, joita ei ole tallennettu paikalliseen tiedostojärjestelmään. Useimmat metodin getLocation() kutsujat käyttivät sitä noutaakseen java.io.File-ilmentymän, jota ei enää voi käyttää paikalliseen tiedostojärjestelmään tallentamattomien resurssien kanssa.
Uudessa org.eclipse.core.filesystem-lisäosassa on yleinen tiedostojärjestelmä-API, jota voi käyttää java.io.File-rajapinnan sijasta. Org.eclipse.core.filesystem.IFileStore-ilmentymän avulla voi käyttää useimpia samoja metodeja kuin kohteen java.io.File kanssa. Seuraava katkelmakoodi noutaa tietyn resurssin IFileStore-ilmentymän:
IResource resource = ...;//jokin resurssi IFileStore store = EFS.getStore(resource.getLocationURI());
Seuraavassa taulukossa on kohteen IFileStore vastaavat metodit toiminnoille, jotka yleensä toteutetaan kohteen java.io.File avulla:
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 |
IFileStore-sovellusohjelmaliittymässä suurin osa tiedostoa koskevista tiedoista on tallennettu rakenteeseen nimeltä IFileInfo, jonka voi noutaa kutsumalla metodia IFileStore.fetchInfo(). Tämä mahdollistaa paremman koodin optimoinnin kohteen java.io.File avulla, koska monet tiedoston määritteet voi noutaa yhdellä tiedostojärjestelmän kutsulla. Huomaa, että IFileInfo-tiedot vanhentuvat, jos niiden perustana oleva tiedosto muuttuu. Tämän vuoksi ilmentymiä tulee käyttää vain niin kauan kuin ne ovat tarpeen. Seuraavassa on joitakin kohteen java.io.File metodeja, joilla on vastaavat metodit kohteessa 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) |
Esimerkiksi koodi, joka aiemmin kutsui metodia java.io.File.exists(), voi nyt kutsua metodia IFileStore.fetchInfo().exists(). Kun kohdetta IFileInfo muokataan, tulokset on tallennettava takaisin metodin IFileStore.putInfo avulla. Seuraava katkelma esimerkiksi muuttaa tiedoston vain luku -määritettä:
IFileStore store = ...;//jokin tiedostovarasto 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);
Samoin kuin metodi getLocation(), projektin kuvaus ei enää välttämättä sijaitse paikallisessa tiedostojärjestelmässä. Metodin IProjectDescription.getLocationURI() avulla voi noutaa resurssin sijainnin muussa tiedostojärjestelmässä.
Jotkin työasemat edellyttävät tiedoston paikallista kopiota. Ne voivat esimerkiksi aloittaa tiedostoon sopivan työkalun tai käyttää muita kuin Eclipsen tunnistavia kirjastoja, jotka voivat käsitellä vain tiedostojärjestelmän resursseja (esimerkiksi java.util.zip.ZipFile). Näissä tapauksissa voit pyytää kohdetta IFileStore palauttamaan välimuistiin tallennetun paikallisen version sen sisällöstä seuraavasti:
IFileStore store = ...;//jokin tiedostovarasto //selvitä, voiko sen esittää suoraan paikallistiedostona java.io.File local = store.toLocalFile(EFS.NONE, null); //jos ei, pyydä välimuistiin tallennettua paikallista tiedostokopiota if (local == null) local = store.toLocalFile(EFS.CACHE, null);
Huomaa, että kun välimuistiin tallennettu tiedostokopio on saatu, se ei pysy tahdistettuna sen tiedostojärjestelmän kanssa, josta tiedosto on peräisin. Välimuistiin tallennetun kopion muokkaus ei muuta alkuperäistä tiedostoa.
Työasemat, jotka eivät pysty käsittelemään paikallisen tiedostojärjestelmän ulkopuolisia resursseja, voivat silti sopeuttaa koodinsa vikaantumiseen. Työasemat voivat tarkistaa, onko resurssi paikallisessa tiedostojärjestelmässä, ja joko ohittaa resurssin tai varoittaa käyttäjää, kun ne eivät voi käsitellä resurssia. Voit selvittää, onko resurssi paikallisessa tiedostojärjestelmässä, selvittämällä sen tiedostojärjestelmän skeeman. Sen voi noutaa resurssista seuraavasti:
IResource resource = ...;//jokin resurssi URI uri = resource.getLocationURI(); if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) { //tiedosto on paikallisessa tiedostojärjestelmässä } else { //tiedosto ei ole paikallisessa tiedostojärjestelmässä }
Jos käytettävissä on IFileStore-ilmentymä, voit noutaa skeeman seuraavasti:
IFileStore store = ...;//tiedostovarasto store.getFileSystem().getScheme();
Mitä muutos koskee: Työasemia, jotka kutsuvat metodia MultiPageEditorSite.progressStart()
tai MultiPageEditorSite.progressEnd()
.
Kuvaus: Eclipsen version 3.0 kehityksen aikana nämä metodit lisättiin osana edistymisen tukityötä. Ennen version 3.0 julkaisua tapa, jolla edistymistä käsiteltiin, muuttui, eikä tämä metodi ollut enää tarpeen. Ohjelmoijan virheen vuoksi nämä julkiset metodit jäivät versioon 3.0. Näillä metodeilla ei ole koskaan ollut käyttöä Eclipsessä, joten ne on poistettu.
Tarvittavat toimet: Työasemat, jotka kutsuvat metodia
MultiPageEditorSite.progressStart()
tai
MultiPageEditorSite.progressEnd()
, on muutettava käyttämään kohdetta
IWorkbenchSiteProgressService
.
Mitä muutos koskee: Työasemia, joissa on mukautettu config.ini ja joita ollaan päivittämässä sovellusversioon 3.2.
Kuvaus: Ennen 3.2-versiota config.ini-tiedostojen
osgi.bundle-resurssijoukkojen tyypillinen arvo oli org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
Ajonaikaisen
koodinparannuksen takia arvoa on päivitettävä, jotta sovellus
voidaan aloittaa.
Tarvittava toimi:Muuta
osgi.bundle-resurssijoukkojen
arvoa seuraavalla lisäyksellä:
org.eclipse.equinox.common@2:start,
org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start.
Mitä muutos koskee: Työasemia, joissa on käytössä RCP-sovellukset ja määritettynä osgi.bundle-arvo.
Kuvaus: Ennen 3.2-versiota jnlp-päätiedoston
osgi.bundle-resurssijoukkojen tyypillinen arvo oli
org.eclipse.core.runtime@2:start,
org.eclipse.update.configurator@3:start
.
Ajonaikaisen
koodinparannuksen takia arvoa on päivitettävä; muussa tapauksessa
saattaa ilmetä NullPointerException
-poikkeuksia, jotka
estävät sovelluksen aloituksen.
Tarvittava toimi:Muuta
osgi.bundle-resurssijoukkojen arvoa seuraavalla lisäyksellä:
org.eclipse.equinox.common@2:start,
org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start.
Mikä muutos koskee: Työasemia, jotka kutsuvat
Bundle.start()
-metodia.
Kuvaus:
Eclipse-ympäristössä resurssijoukko on määritetty
Eclipse-LazyStart
-otsikon (tai vanhentuneen
Eclipse-AutoStart
-otsikon) avulla lazy start -resurssijoukoksi. Eclipsen
versiossa 3.1 metodi org.osgi.framework.Bundle.start()
ei merkinnyt lazy start -resurssijoukkoja pysyvästi aloitettaviksi. Koska
resurssijoukkoja ei ollut merkitty pysyvästi aloitettaviksi, niitä ei
aloitettu automaattiseti, kun Eclipse aloitettiin uudelleen. Bundle.start()
-metodin
javadoc-dokumentaatiossa todetaan, että metodin kutsumiseen liittyy
seuraavia ehtoja:
"Tallenna tämän resurssijoukon aloitus pysyvästi. Kun kehys aloitetaan uudelleen, resurssijoukko on aloitettava automaattisesti."
Eclipsen versiossa 3.2 Bundle.start()
-metodi on
korjattu niin, että se merkitsee resurssijoukon pysyvästi
aloitettavaksi, vaikka resurssijoukko on lazy start -määritteinen. Tämä
korjaus oli pakko tehdä OSGi-kehysmäärityksen perusteella. Kun
Bundle.start()
-metodia nyt kutsutaan, resurssijoukko
aloitetaan aina, kun Eclipse aloitetaan uudelleen. Yleensä tätä on pidetty huonona käytäntönä, koska jokaisella Eclipsen
aloituskerralla aktivoidaan silloin turhia resurssijoukkoja. Toisinaan
tästä voi olla odottamattomia seurauksia (ks. esimerkiksi vika
134412).
Tarvittava toimi:
Bundle.start()
-metodia käyttävissä työasemissa on
arvioitava, halutaanko resurssijoukko aktivoida pysyvästi jokaiseen
uudelleenaloitukseen. Jos tätä ei haluta, työasemiin on keksittävä
jokin toinen tapa aktivoida resurssijoukko. Useimmiten
Bundle.start()
-kutsut voi välttää yksinkertaisesti niin,
että sallitaan kohderesurssijoukon lazy-aktivointi, kun siitä
ladataan luokkia. Joissakin harvoissa tapauksissa lazy start
-resurssijoukko joudutaan aktivoimaan aggressiivisesti, mutta sitä ei
silti tarvitse merkitä pysyvästi aktivoitavaksi
uudelleenaloituksen yhteydessä. Tällaisissa tapauksissa
aktivoitava resurssijoukko pitäisi ladata
Bundle.loadClass()
-metodin avulla sen sijaan, että
kutsutaan Bundle.start()
-metodia.
Eclipsen versiossa 3.0 alaviivan (_) käyttöä
versiotunnuksen tarkenteessa ei tuettu, mutta sitä ei ollut myöskään
estetty. Jos lisäosan versiotunnuksen tarkenteessa oli alaviiva,
merkki muunnettiin yhdysviivaksi (-), kun lisäosa tuotiiin
tiedostojärjestelmään tai kun sitä asennettiin päivityssivustosta.
Eclipsen versiossa 3.1 tarkenteissa sallittuja merkkejä koskevia
sääntöjä löyhennettiin ja myös alaviiva sallittiin. Tarkennetta ei
enää muutettu sääntöjenvastaisen lisäosan viennin tai asennuksen
yhteydessä. Tämä pieni muutos jäi vahingossa pois 3.0 -
3.1-siirtymäoppaasta.
Tulevaisuudessa (ja Eclipsen versiossa 3.2) pidetään yllä
yhteensopivuutta Eclipse 3.1:n ja sellaisten lisäosien kanssa, joissa
on käytetty alaviivaa version tarkenteissa. Edellä mainitut muutokset
on kuitenkin otettava huomioon, kun käytetään vanhoja
lisäosaversioita (sekä näiden lisäosien viennissä että niiden
päivityssivustoversioiden yhteydessä). Niinpä esimerkiksi sellaisten
lisäosien toimittajien, joilla on vanhoja lisäosaversioita
päivityssivustoissaan, täytyy varmistaa, että lisäosan nimi
tiedostojärjestelmässä vastaa sen todellista nimeä.