Epäyhteensopivuudet Eclipse 3.1- ja 3.2-versioiden välillä

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.

  1. Resurssit eivät enää välttämättä ole paikallisessa tiedostojärjestelmässä
  2. MultiPageEditorSite-sovellusohjelmaliittymän muutokset
  3. Sisältömuutokset config.ini-tiedostossa
  4. Sisältömuutokset jnlp-sovelluksissa
  5. Eksplisiittiset Bundle.start()-kutsut aiheuttavat resurssijoukon pakollisen aktivoinnin seuraavan uudelleenkäynnistyksen yhteydessä
  6. Alaviivaa ei enää korvata yhdysviivalla lisäosien versionumeroissa

1. Resurssit eivät enää välttämättä ole paikallisessa tiedostojärjestelmässä

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.FileIFileStore
deletedelete
getNamegetName
getParentgetParent
listchildNames
mkdirmkdir(EFS.SHALLOW, null)
mkdirsmkdir(EFS.NONE, null)
renameTomove
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.FileIFileInfo
canWriteisReadOnly
existsexists
getNamegetName
isDirectoryisDirectory
isFile!isDirectory()
isHiddenisHidden
lastModifiedgetLastModified
lengthgetLength
setLastModifiedsetLastModified
setReadOnlysetAttribute(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);

IProjectDescription.getLocation()

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ä.

Paikallinen välimuisti

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.

Häiriö

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();

2. MultiPageEditorSite - ohjelmointirajapinnan muutokset

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.

3. Sisältömuutokset config.ini-tiedostossa

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.

4. Sisältömuutokset jnlp-sovelluksissa

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.

5. Eksplisiittiset Bundle.start()-kutsut aiheuttavat resurssijoukon pakollisen aktivoinnin seuraavan uudelleenaloituksen yhteydessä

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.

5. Alaviivaa ei enää korvata yhdysviivalla lisäosien versionumeroissa

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ä.