Inkompatibilitás az Eclipse 2.1 és 3.0 verzió között

Az Eclipse inkompatibilis módon változott a 2.1 és 3.0 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 2.1 verziószámú bedolgozók átállításához a 3.0 verzióra. Ezeket csak akkor kell megtekintenie, ha problémája van a 2.1 verziószámú bedolgozó futtatásával a 3.0 verzión.

  1. Bedolgozó leírófájl verzió
  2. A Platform UI bedolgozók átstrukturálása
  3. A platform alap futási bedolgozók átstrukturálása
  4. A Xerces bedolgozó eltávolítása
  5. Az Eclipse 3.0 verzióban több a párhuzamosság
  6. Szerkesztők megnyitása IFiles szoftveren
  7. Szerkesztő ugrásjelző
  8. Szerkesztőindító
  9. Szerkesztőnyilvántartás
  10. Munkaterület jelzősúgó-nyilvántartás
  11. Szövegszerkesztő-dokumentumszolgáltatók
  12. Szövegszerkesztők
  13. Megjelenítés nélküli feljegyzéstámogatás
  14. Konzolnézet
  15. Java töréspontfigyelők
  16. Vágólap hozzáférés UI szálban
  17. Billentyűlenyomási események
  18. Tab billentyűvel végiglépkedés az egyedi vezérlőelemeken
  19. Kiválasztási eseménysorrend az SWT táblázatban és a fa felületi elemekben
  20. Új fontossági szint az állapotobjektumokban
  21. Összeépítéssel kapcsolatos erőforrásmódosítási értesítések
  22. Köztes értesítések a munkaterület-műveletek során
  23. URL folyamkezelő-kiterjesztések
  24. Osztálybetöltési sorrend
  25. Osztálybetöltő-védelmi tartomány nincs beállítva
  26. PluginModel objektum átalakítása
  27. Az ILibrary megvalósítása befejezetlen
  28. Érvénytelen feltételezések az URL címek formáját tekintve
  29. Áthelyezett/törölt BootLoader metódusok
  30. A bedolgozóexportálás automatikusan nem foglalja magában a bedolgozók JAR fájljait
  31. Futási API újbóli exportálása
  32. Bedolgozóelemzési metódusok a platformon
  33. A töredékek által biztosított bedolgozó-függvénytárak
  34. Az összeépítési parancsfájlok módosításai
  35. A PDE összeépítési Ant feladat módosításai
  36. Az eclipse.build Ant feladat módosításai
  37. Az eclipse.fetch Ant feladat módosításai
  38. Az install.ini helyettesítése

1. Bedolgozó leírófájl verzió

A bedolgozók (és bedolgozótöredékek) leírófájljainak fejlécébe bekerült egy új sor, amely azonosítja a megfelelő bedolgozó leírófájl verziót. A 3.0 verzió előtt a bedolgozók nem tartalmazták az <?eclipse ...?> sort; a 3.0 verzió után mindig rendelkezniük kell egy ilyen sorral. Ez a változás lehetővé teszi, hogy az Eclipse futási környezet felismerje a 3.0 verziónál korábbi, 3.0 verzióra átállított bedolgozókat, így automatikusan jobb bináris kompatibilitást biztosíthatnak ezen bedolgozók számára. Ez a plugin.xml fájl általános formája (a fragment.xml hasonló):

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
    ...
</plugin>

A PDE 3.0 által létrehozott bedolgozó leírófájlok automatikusan ezt a formátumot kapják. Erősen ajánlott a PDE bedolgozóátállítási eszközt használni. Ez automatikusan beszúrja a jelzett sort a 2.1 verziószámú bedolgozók és bedolgozótöredékek leírófájljába, és az itt leírt számos más változás problémáját is megoldja.

Ha hozzáadja ezt a direktívát a plugin.xml fájlhoz (kézzel vagy PDE segítségével), akkor a fájlt frissíteni kell, hogy explicit módon jelenítse meg azokat a bedolgozókat, amelyektől függ. Az Eclipse 3.0 verzió előtt például az org.eclipse.core.runtime és org.eclipse.core.boot függőségei implicit módon voltak megadva. A 3.0 verzióban az org.eclipse.core.boot elemre nincs szükség, és a fejlesztőknek az org.eclipse.core.runtime vagy org.eclipse.core.runtime.compatibility (vagy egyiket sem) elemet kell választaniuk.

Megjegyzés: Ez az egyik inkompatibilitás, amely nincs hatással arra, hogy az Eclipse 3.0 hogyan futtatja a 2.1 bedolgozókat.

2. A Platform UI bedolgozók átstrukturálása

Az org.eclipse.ui bedolgozó, amely a fő Platform UI bedolgozó, csak az alkalmazás programozási felületet és a kiterjesztési pontokat biztosítja az általános (azaz nem IDE specifikus) munkaterülethez. Az elhagyható és IDE specifikus API, valamint a kiterjesztési pontok átkerültek másik bedolgozókra.

Ezen módosítás hatása kétszeres: (1) az áthelyezett org.eclipse.ui kiterjesztési pontok új kiterjesztési pont azonosítókat kapnak; és (2) a szükséges bedolgozók listája megváltozik.

Az alábbi táblázatban lévő org.eclipse.ui kiterjesztési pontok átkerültek különböző bedolgozókra, amelynek hatására kiterjesztési pont azonosítójuk megváltozott. Ha egy meglévő bedolgozó egy kiterjesztést biztosít az áthelyezett kiterjesztési pontokhoz, akkor a bedolgozó leírófájl <extension> elemének "point" attribútumában lévő hivatkozást módosítani kell, hogy a megfelelő új kiterjesztési pont azonosítókra mutasson. A PDE bedolgozóátállítási eszköz megoldja ezeket a problémákat.

Megjegyzés: Ez az egyik inkompatibilitás, amely nincs hatással arra, hogy az Eclipse 3.0 verzió hogyan futtatja a 2.1 bináris bedolgozókat. Az Eclipse 3.0 futási környezet automatikusan felismeri a 3.0 verziónál korábbi bedolgozókat (a bedolgozó leírófájlban a korábban említett <?eclipse version="3.0"?> sor hiánya alapján), és automatikusan kompenzálja ezeket a kiterjesztési pont és bedolgozófüggőségi változásokat.

Régi kiterjesztési pont azonosító

Új kiterjesztési pont azonosító

org.eclipse.ui.markerHelp org.eclipse.ui.ide.markerHelp
org.eclipse.ui.markerImageProviders org.eclipse.ui.ide.markerImageProviders
org.eclipse.ui.markerResolution org.eclipse.ui.ide.markerResolution
org.eclipse.ui.projectNatureImages org.eclipse.ui.ide.projectNatureImages
org.eclipse.ui.resourceFilters org.eclipse.ui.ide.resourceFilters
org.eclipse.ui.markerUpdaters org.eclipse.ui.editors.markerUpdaters
org.eclipse.ui.documentProviders org.eclipse.ui.editors.documentProviders
org.eclipse.ui.workbench.texteditor.
markerAnnotationSpecification
org.eclipse.ui.editors.markerAnnotationSpecification

Az alábbi táblázat felsorolja az org.eclipse.ui bedolgozó által korábban biztosított API csomagokat, amelyek áthelyezésre kerültek különböző bedolgozókhoz. (Az API csomagok, osztályok, mezők és metódusok neve nem változott.) Néhány esetben az API csomagok több bedolgozóra terjednek ki. Mivel az adott bedolgozó által látható API osztályokat a bedolgozó szükséges bedolgozók listája határozza meg, a változásokhoz szükség lehet a "<szükséges>" elemek beállítására egy meglévő bedolgozó leírófájljában az API osztály elérésének visszaszerzése érdekében.

Ez a változás csak azon bedolgozókra van hatással, amelyek az org.eclipse.ui bedolgozótól függenek (azaz tartalmazza az <import plugin="org.eclipse.ui"/> sort a bedolgozó leírófájl <szükséges> részében); a többi bedolgozót nem befolyásolja. Ha hatással van rá, akkor szükség lehet az <import> elem módosítására, vagy további <import> elemek felvételére, így az összes API osztály, amelyre a bedolgozónak szüksége van, megtalálható. Ajánlatos, hogy a bedolgozók csak a valójában használt bedolgozókról állítsák, hogy függenek tőle. A szükségtelen függőségek csökkentik a futási teljesítményt, mivel a Java osztálybetöltőnek meg kell keresnie az összes függőségben lévő osztályt. (A PDE bedolgozóátállítási eszköz kijavítja ezeket a függőségeket, és segít a minimális halmaz meghatározásában.)

API csomag

2.1 bedolgozó

Megfelelő 3.0 bedolgozó(k)

org.eclipse.jface.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.ui org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.actions org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.dialogs org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.editors.* org.eclipse.ui org.eclipse.ui.editor
org.eclipse.ui.model org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.part org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.texteditor org.eclipse.ui org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors
org.eclipse.ui.texteditor.* org.eclipse.ui org.eclipse.ui.workbench.texteditor
org.eclipse.ui.views.bookmarkexplorer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.contentoutline org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.markers org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.navigator org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.properties org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.tasklist org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.datatransfer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.newresource org.eclipse.ui org.eclipse.ui.ide

3. A platform alap futási bedolgozók átstrukturálása

Az Eclipse 3.0 Platform futási környezet az OSGi-re épül, és megköveteli a két Platform futási bedolgozó, az org.eclipse.core.runtime és org.eclipse.core.boot módosítását.

Az új org.eclipse.core.runtime.compatibility bedolgozó egy megvalósítási hidat biztosít a régi és új alkalmazás programozási felületek között, és ez új otthona a korábban az org.eclipse.core.runtime és org.eclipse.core.boot elemben megtalálható elavult alkalmazás programozási felületeknek. Az átsrtukturálás a platform futási kiterjesztési pontokra nincs hatással.

A meglévő bedolgozó 3.0 verzióra átállításakor a bedolgozó leírófájlját frissíteni kell az Eclipse platform futási bedolgozók új struktúrájának tükrözése érdekében. A PDE bedolgozó leírófájl-átállítási eszköz függőséget ad hozzá az org.eclipse.core.runtime.compatibility elemhez, amennyiben szükséges.

Ha a bedolgozót 3.0 verziószámmal jelöli meg (az <?eclipse version="3.0"?> segítségével), és a bedolgozó megad egy Bedolgozó osztályt, akkor explicit módon meg kell adni az <import plugin="org.eclipse.core.runtime.compatibility"/> sort a bedolgozó leírófájlban, vagy biztosítani kell, hogy a Bedolgozó osztály megadja az alapértelmezett konstruktort.

Megjegyzés: Ez az egyik inkompatibilitás, amely nincs hatással arra, hogy az Eclipse 3.0 verzió hogyan futtatja a 2.1 bináris bedolgozókat. Az Eclipse 3.0 futási környezet automatikusan felismeri a 3.0 verziónál korábbi bedolgozókat (a bedolgozó leírófájlban az <?eclipse version="3.0"?> sor hiánya alapján) és automatikusan kompenzálja a Platform futási környezet ezen változásait.

4. A Xerces bedolgozó eltávolítása

Az org.eclipse.xerces bedolgozó a továbbiakban nem szükséges, és törlésre került. Az XML elemzési támogatás be van építve a J2SE 1.4 verzióba, és a Xerces bedolgozó jelenléte osztálybetöltő konfliktust okoz. Az org.eclipse.xerces bedolgozó által korábban biztosított javax.xml.parsers, az org.w3c.dom.* és az org.xml.sax.* API csomag most a J2SE függvénytárakból érhető el.

Ha a bedolgozónak szüksége van az org.eclipse.xerces bedolgozóra, akkor a bedolgozó leírófájlt módosítani kell a megadott függőségek eltávolítása érdekében. Ha ez megtörtént, akkor a bedolgozó kódját le kell fordítani és további módosítás nélkül kell futtatni.

A 2.1 bináris bedolgozók az org.eclipse.xerces bedolgozó megadott függőségeivel egy előfeltételt fognak hiányolni a szabványos Eclipse 3.0 konfigurációban futtatáskor. A bedolgozó ennek közvetkeztében nem kerül aktiválásra.

5. Az Eclipse 3.0 verzióban több a párhuzamosság

Az Eclipse 3.0 verzió előtt az Eclipse többnyire egy szálban működött. A legtöbb API metódus és kiterjesztési pont az UI szálban, vagy egy előrehaladás párbeszédablakból elindított szálban működik, amelyet az UI szál blokkol. A legtöbb bedolgozóírónak nem kell aggódnia a szálbiztonság miatt, annak ellenőrzésétől eltekintve, hogy az összes UI tevékenység az UI szálban történik-e. Az Eclipse 3.0 verzióban általában több a párhuzamosság. Számos művelet háttérben futó szálban történik, ahol más szálakkal egyidejűleg futhatnak, az UI szálat is beleértve. Az összes bedolgozónak, amelyek kódja egy háttérben futó szálban fut, ismerniük kell a kód szálbiztonságát.

A bedolgozókon kívül, amelyek az org.eclipse.core.runtime.jobs API segítségével a háttérben explicit módon futtatnak műveleteket, számos platform API lehetőség és kiterjesztési pont van, amely háttérben futó szálakat használ. A szolgáltatásokba csatlakozó bedolgozóknak biztosítani kell, hogy a kód biztonságos szálban legyen. Az alábbi táblázat összefoglalja az alkalmazás programozási felületet és kiterjesztési pontokat, amelyek a kód egy részét, vagy teljes egészét egy háttérben futó szálban futtatja az Eclipse 3.0 verzióban:

Az API osztály kiterjesztési pontja

Megjegyzések

org.eclipse.core.runtime.IRegistryChangeListener Az Eclipse 3.0 újdonsága, hogy háttérben fut
org.eclipse.core.resources.IResourceChangeListener az AUTO_BUILD események a háttérben futnak
org.eclipse.core.resources.builders (ext. point) Automatikus összeépítés a háttérben
org.eclipse.core.resources.ISaveParticipant a SNAPSHOT a háttérben fut
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (ext. point) Az Eclipse 3.0 újdonsága, hogy háttérben fut
org.eclipse.ui.decorators (ext. point) Már az Eclipse 2.1 verzióban is a háttérben futott
org.eclipse.ui.startup (ext. point) Már az Eclipse 2.1 verzióban is a háttérben futott
org.eclipse.team.core.org.eclipse.team.core.repository (kiterjesztési pont) Számos művelet fut most a háttérben
org.eclipse.team.ui.synchronizeParticipants (kiterjesztési pont) Az Eclipse 3.0 újdonsága, hogy háttérben fut
org.eclipse.debug.core.launchConfigurationTypes (kiterjesztési pont) Most háttérben fut
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD most háttérben fut, a POST_RECONCILE már korábban is a háttérben futott

Számos stratégia áll rendelkezésre a kód szálbiztonságának megvalósítása érdekében. Egy naív megoldás annak biztosítása, hogy az összes munka az UI szálban történik, amely sorozatos végrehajtást biztosít. Ez az UI bedolgozó általános megközelítése, amely nem végez CPU igényes feldolgozást. Ennek végrehajtásakor figyeljen a Display.syncExec öröklött holtpontkockázatára. A Display.asyncExec általában biztonságosabb, ha nem vezet be holtpontkockázatot, a pontos vezérlés elvesztésének költsége a kód végrehajtása során.

A szálbiztonságos kód elkészítésének egyéb módszerei:

6. Szerkesztők megnyitása az IFile-okon

Az alábbi metódusok törlésre kerültek az org.eclipse.ui.IWorkbenchPage felületről. Az IWorkbenchPage az általános munkaterületen került megadásra, de a metódusok öröklötten erőforrás-specifikusak.

Ezen IWorkbenchPage.openEditor metódusok ügyfeleinek meg kell hívnia a az org.eclipse.ui.ide.IDE (az org.eclipse.ui.ide bedolgozóban) osztályban megadott megfelelő nyilvános statikus metódusokat.

Ezen IWorkbenchPage.openSystemEditor(IFile) metódusok ügyfeleinek az új FileEditorInput(IFile) metódus segítségével át kell alakítaniuk az IFile-t egy IEditorInput elemmé, majd meg kell hívniuk az openEditor(IEditorInput,String) metódust. Más szavakkal átírja a page.openSystemEditor(file) metódust page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID) metódussá. Megjegyzés: az IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID szerkesztőazonosítókat használó ügyfeleknek át kell adnia egy szerkesztőbemenetet, amely megvalósítja az org.eclipse.ui.IPathEditorInput elemet (amelyet a FileEditorInput tesz).

Megjegyzés: Ez az egyik inkompatibilitás, amely nincs hatással arra, hogy az Eclipse 3.0 verzió hogyan futtatja a 2.1 bináris bedolgozókat. Az Eclipse 3.0 egy bináris futási kompatibilitási mechanizmust tartalmaz, amely a törölt openEditor és openSystemEditor metódusok segítségével biztosítja, hogy a meglévő 2.1 bedolgozó bináris elemek az API módosítás ellenére továbbra is úgy működjenek, mint a 2.1 verzióban. (A törölt metódusokat az org.eclipse.ui.workbench.compatibility töredék "visszaadja".)

7. Szerkesztő ugrásjelző

Az alábbi metódus törlésre került az org.eclipse.ui.IEditorPart felületről. Az IEditorPart az általános munkaterületen került megadásra, de a metódus öröklötten erőforrás-specifikus.

A megfelelő metódusok szintén törlésre kerültek az org.eclipse.ui.part csomag osztályaiból, amelyek megvalósítják az IEditorPart részt, név szerint az EditorPart, a MultiEditor, a MultiPageEditorPart és a MultiPageEditor elemet. 

Ezen metódust meghívó ügyfeleket tesztelni kell, hogy a szerkesztőrész megvalósítja, vagy adaptálódik az org.eclipse.ui.ide.IGotoMarker elemhez (az org.eclipse.ui.ide bedolgozóban), és ez esetben meghívja a gotoMarker(IMarker) metódust. Az IDE osztály egy megfelelő metódust biztosít ehhez: IDE.gotoMarker(editor, marker);

A szerkesztőt megvalósító ügyfeleknek, amelyek az IMarker információk alapján pozícionálni tudják magukat, meg kell valósítanuk vagy adaptálódniuk kell az org.eclipse.ui.ide.IGotoMarker elemhez.

Mivel az IGotoMarker egyetlen metódusa a gotoMarker(IMarker), és ugyanazzal az aláírással és specifikációval rendelkezik, mint a régi IEditorPart.gotoMarker(IMarker), a meglévő szerkesztőmegvalósítások adaptálódhatnak ehhez a változáshoz azáltal, hogy az IGotoMarker belekerül az osztálydefiníció megvalósítási mellékmondatába.

Ezen metódust meghívó kódot tartalmazó 2.1 bináris bedolgozók szabványos Eclipse 3.0 konfigurációban futáskor osztály-összeszerkesztési hiba kivételt kapnak.

8. Szerkesztőindító

Az org.eclipse.ui.IEditorLauncher szerkesztőindító-felületet a külső szerkesztőket biztosító bedolgozók valósítják meg. Az alábbi metódus eltávolításra került a felületről. Az IEditorLauncher az általános munkaterületen került megadásra, de a metódus öröklötten erőforrás-specifikus.

Ezt az alábbi helyettesíti:

Az ügyfeleknek az IEditorLauncher.open(file) helyett az IEditorLauncher.open(file.getLocation()) metódust kell meghívniuk. Ezen felületet megvalósító ügyfeleknek le kell cserélniük (vagy kiegészíteni) az open(IFile) megvalósítást az open(IPath) metódusra.

Ezen metódust meghívó kódot tartalmazó 2.1 bináris bedolgozók szabványos Eclipse 3.0 konfigurációban futáskor osztály-összeszerkesztési hiba kivételt kapnak.

9. Szerkesztőnyilvántartás

Az alábbi metódus eltávolításra került az org.eclipse.ui.IEditorRegistry felületről. Az IEditorRegistry az általános munkaterületen került meghatározásra, de a metódusok öröklötten erőforrás-specifikusak.

A getEditors(file) vagy getImageDescriptor(file) metódusokat meghívó ügyfeleknek meg kell hívnia a "String" elemnek megfelelő metódusokat: Az ügyfeleknek a setDefaultEditor(IFile file, String editorId) és getDefaultEditor(IFile file) metódus helyett az org.eclipse.ui.ide.IDE (in the org.eclipse.ui.ide plug-in) osztályban megadott megfelelő nyilvános statikus metódusokat kell meghívni: Ezenfelül módosult az IEditorRegistrygetDefaultEditor() metódus API-szerződése is. Ez a metódus már elavult, és mindig a System External Editor szerkesztőleírót adja vissza. Ez a változás hatással van azokra az ügyfelekre, amelyek feltételezték, hogy a visszaadott alapértelmezett szerkesztő egy szövegszerkesztő.

Új állandók vannak, amelyek a rendszer külső és helyben lévő szerkesztő azonosítóit ábrázolják (SYSTEM_EXTERNAL_EDITOR_ID és SYSTEM_INPLACE_EDITOR_ID). Ez a két szerkesztő egy szerkesztőbemenetet igényel, amely megvalósítja az org.eclipse.ui.IPathEditorInput elemet. Ne feledje el, hogy a helyben lévő szerkesztőleíró nem létezik a helyi szerkesztést nem támogató Eclipse konfigurációkban.

10. Munkaterület jelzősúgó-nyilvántartás

Az alábbi metódus törlésre került az org.eclipse.ui.IWorkbench felületről. Az IWorkbench az általános munkaterületen került megadásra, de a metódus öröklötten erőforrás-specifikus.

Az ügyfeleknek az IWorkbench.getMarkerHelpRegistry() helyett a nyilvános statikus org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() metódust kell meghívniuk (az org.eclipse.ui.ide bedolgozóban).

A metódust meghívó kóddal rendelkező 2.1 bináris bedolgozók kivételt kapnak szabványos Eclipse 3.0 konfigurációban futáskor.

11. Szövegszerkesztő-dokumentumszolgáltatók

Annak érdekében, hogy az org.eclipse.ui.texteditor.AbstractTextEditor az IFile-tól független legyen, az org.eclipse.ui.texteditor.AbstractDocumentProvider bevezeti a dokumentumszolgáltató-művelet (DocumentProviderOperation) és a dokumentumszolgáltató-művelet futó (IRunnableContext) alapelvet. Ha visszaállítást, mentést vagy szinkronizálást kell végrehajtani, akkor az AbstractDocumentProvider létrehozza a dokumentumszolgáltató-műveleteket, és a műveletfuttatót használja ezek végrehajtásához. A futtatható kontextust az alosztályok biztosíthatják a getOperationRunner metóduson keresztül. Az alábbiakban látható a változások összegzése, amelyekhez az ügyfeleknek adaptálódniuk kell:

Az AbstractDocumentProvider org.eclipse.ui.editors.text.StorageDocumentProvider alosztálya megvalósítja a getOperationRunner metódust, hogy mindig nullértéket adjon vissza. Ez azt jelenti, hogy a StorageDocumentProvider alosztályaira ez a módosítás nem lehet hatással.

A StorageDocumentProvider org.eclipse.ui.editors.text.FileDocumentProvider alosztály megvalósítja a getOperationRunner metódust, amely egy IRunnableContext elemet ad vissza az adott DocumentProviderOperations WorkspaceModifyOperation műveleten belüli végrehajtásához. A FileDocumentProvider egyéb változtatásai az alábbiak:

12. Szövegszerkesztők

Az org.eclipse.ui.texteditor.AbstractTextEditor módosításai:

Az AbstractTextEditor org.eclipse.ui.texteditor.StatusTextEditor alosztály az isErrorStatus(IStatus) predikátum metódust biztosítja. Az alosztályok újradefiniálhatók annak eldöntése érdekében, hogy az adott állapotot hibaként kell-e kezelni.

Az org.eclipse.ui.editors.text.AbstractDecoratedTextEditor módosításai:

13. Megjelenítés nélküli feljegyzéstámogatás

A megjelenítés nélküli feljegyzéstámogatás bevezetésének részeként a Feljegyzésen az alábbi módosítások történtek:

        org.eclipse.jface.text.source.Annotation 
        org.eclipse.jface.text.source.AnnotationModel 
        org.eclipse.jface.text.source.AnnotationModelEvent 
        org.eclipse.jface.text.source.IAnnotationModel 
        org.eclipse.jface.text.source.IAnnotationModelListener 
        org.eclipse.jface.text.source.IAnnotationModelListenerExtension

14. Konzolnézet

Az Eclipse 3.0 új általános konzoltámogatással rendelkezik. Az általános konzol az Ablak > Megjelenítés nézet > Alap > Konzol lehetőségen keresztül érhető el, és az Eclipse hibakeresés valamint az Ant integráció használja.

A konzol nézetazonosítója org.eclipse.debug.ui.ConsoleView értékről org.eclipse.ui.console.ConsoleView értékre változott. A konzolt programból megnyitó 2.1 bedolgozók sikertelenek lesznek, mivel a régi nézet már nem létezik.

15. Java töréspontfigyelők

A 3.0 verzióban az org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) és installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) metódus visszatérési típusa logikai értékről egész értékre változott annak érdekében, hogy a figyelők "don't care" szavazatot adhassanak. A 3.0 előtti kiadásokban a figyelők töréspont észlelésekor csak "suspend" vagy "don't suspend" szavazatot küldhetnek, vagy "install" illetve "don't install" szavazatot, ha a töréspont telepítése a kérdés. A 3.0 verzióban a figyelők "don't care" szavazatot is adhatnak ezekre az értesítésekre. Ennek segítségével az ügyfelek csak döntő szavazatot adhatnak az őket érintő helyzetekben. "Töréspont találat" értesítés esetén a töréspont felfüggesztésre kerül, amennyiben a figyelők szavazata "suspend", vagy az összes figyelő szavazata "don't care"; és nem kerül felfüggesztésre, amennyiben legalább egy figyelő szavazata "don't suspend", és egyik szavazat sem "suspend". Ehhez hasonlóan a "töréspont-telepítés" értesítések esetén a töréspont telepítésre kerül, amennyibben minden figyelő szavazata "don't care"; és nem kerül telepítésre, ha legalább egy figyelő szavazata "don't install", és egyiké sem "install". A megvalósítóknak általában DONT_CARE értéket kell visszadniuk, hacsak nincs konkrét véleményük. Ne feledje el, hogy a "suspend" szavazat felülbírálja másik figyelő "don't suspend" szavazatát.

Az IJavaBreakpointListener felületet azon ügyfelek valósítják meg, akik létrehoznak vagy reagálnak a Java kódban lévő töréspontokra. Valószínűleg a JDT-n magán kívül kevés ügyfél lehet ilyen, kivéve azt, amelyik jelentette azt a problémát ( 37760-as hiba), amelyet ez a módosítás orvosol. Ez az IJavaBreakpointListener felületet megvalósító meglévő kód lényeges módosítása. Ezt a kódot a lefordítás vagy a 3.0 verzióban futtatás előtt módosítani kell, hogy a megfelelő egész értéket adja vissza.

16. Vágólap-hozzáférés egy UI szálban

A 3.0 előtt az SWT org.eclipse.swt.dnd.Clipboard osztály metódusai számára engedélyezve lett, hogy ne az UI szálban fussanak. Ennek eredményeképp hibák lépnek fel a GTK-n, amelyen az operációs rendszer megköveteli, hogy az összes vágólapinterakció az UI szálban fusson. Ez a probléma nem lett korábban felfedezve, mivel számos alkalmazás egy szállal rendelkezik, és a legtöbb tesztelés Windowson történik. Annak érdekében, hogy a Vágólap API fenntartható és többplatformos legyen, a 3.0 verzióban a Vágólap API metódusok specifikációja és megvalósítása módosítva lett, hogy nem UI szálból meghívás esetén SWT kivételt dobjon (ERROR_THREAD_INVALID_ACCESS). A vágólap-szolgáltatásokat az Eclipse összetevők - mint például a szövegszerkesztő - automatikusan biztosítják, amely számos ügyfelet elszigetel ezen jelentős módosításoktól. A vágólapot közvetlenül használó kódnak ellenőriznie kell, hogy az API metódusok a megfelelő szálban kerülnek-e meghívásra a Display.asyncExec vagy syncExec segítségével, amikor a hozzáférések eltolhatók az UI szálba.

17. Billentyűlenyomási események

A 3.0 verzióban az SWT jelentést készít a billentyűlenyomási eseményekről, mielőtt a feladat végrehajtásra kerülne az operációs rendszerben. Ez sokkal előbb történik, mint ahogy a 3.0 verzió előtt történt. Az Eclipse szoftver módosítása a billentyűkombinációk-támogatása érdekében történt, amely ahhoz szükséges, hogy a billentyűesemények elfogásra kerüljenek az előtt, hogy a felületi elemek feldolgozhatnák a karaktert. Ezen változtatás következménye látható a kódban, amely közvetlenül kezeli az alacsony szintű org.eclipse.swt.SWT.KeyDown eseményeket. Ez azt jelenti például, hogy amikor a Szöveg felületi elem figyelője billentyűlenyomási eseményt kap, akkor a felületi elem tartalma (getText()) még nem tartalmazza az éppen lenyomott billentyűt (a 3.0 előtti verzióban tartalmazná). A felületi elem teljes szövegének - az aktuális billentyűt is beleértve - lekéréséhez ajánlott módszer a magasabb szintű SWT.Modify vagy SWT.Verify események kezelése az alacsonyabb szintű SWT.KeyDown esemény kezelése helyett; a kódra, amely már így valósítja meg, nincs hatással ez a módosítás.

18. Tab billentyűvel végiglépkedés az egyedi vezérlőelemeken

A 3.0 előtti verzióknál ha a fókusz az SWT org.eclipse.swt.widgets.Canvas elemen vagy ennek egyik alosztályán volt (az egyéni felületi elemeket is beleértve), akkor a Ctrl+Tab, Shift+Tab, Ctrl+PgUp vagy Ctrl+PgDn billentyűkombináció lenyomása automatikusan aktiválja a következő/előző felületi elem végigjárást a billentyűesemény jelentése nélkül. Ez a viselkedés nem lett megadva, és egy számlálót futtat ahhoz a szabályhoz, amely szerint a rajzolási területek minden begépelt betűt látnak. A bejárás kezelésének megfelelő módja a bejárásfigyelő bejegyzése. Az Eclipse billentyűkombinációk megfelelő támogatása érdekében a 3.0 verzióban az alapértelmezett viselkedés módosítva lett, így a rajzolási terület a bejárás helyett a Ctrl+Tab, Shift+Tab, Ctrl+PgUp és Ctrl+PgDn billentyűeseményeket látja. Ha nyers rajzolási területet használ vagy a rajzolási terület egy alosztályát adja meg, akkor győződjön meg róla, hogy bejegyez egy bejárásfigyelőt.

19. Kiválasztási eseménysorrend az SWT táblázatban és a fa felületi elemekben

Az elemek egérrel kiválasztása az SWT org.eclipse.swt.widgets.Table és Tree osztályban egy Egérgomblenyomás-Kijelölés-Egérgombfelengedés eseménysorozatot állít elő egységesen az összes működési környezetben. Ehhez hasonlóan a billentyűzetkijelölések a Billentyűlenyomás-Kijelölés-Billentyűfelengedés eseménysorozatot állítják elő egységesen az összes működési környezetben. A 3.0 verzió előtt az eseménysorrend nem volt egységes, a Motif és Photon szoftverben megvolt az a különbség, hogy mindig elsőként a kijelöléseseményről készíttetek jelentést; azaz Kijelölés-Egérgomblenyomás-Egérgombfelengedés vagy Kijelölés-Billentyűlenyomás-Billentyűfelengedés. A 3.0 verzióban az eseménysorrend a Motif és Photon szoftveren megváltozott, hogy megfeleljenek a többieknek. A {Windows, GTK} és {Motif, Photon} rendszeren egyaránt jól működő kódot valószínűleg nem befolyásolja. De érdemes ellenőrizni a kódot, hogy nem épül-e érvénytelen eseménysorrendre.

20. Új fontossági szint az állapotobjektumokban

Az org.eclipse.core.runtime.IStatus rendelkezik egy új fontossági állandóval - IStatus.CANCEL -, amely a törlést jelzi. A IStatus.getSeverity() meghívóira, amelyek az IStatus.OK, INFO, WARNING és ERROR korlátozott lehetséges fontossági halmazára épülnek, hatással van ez a hozzáadás. A getSeverity meghívóinak az új fontosság tartalmazása érdekében frissíteniük kell a kódot.

21. Összeépítéssel kapcsolatos erőforrásmódosítási értesítések

Az Eclipse 3.0 verzióban a munkaterület automatikus összeépítések egy háttérben futó szálban történnek. Ehhez az API-szerződést módosítani kellett az org.eclipse.core.resources.IResourceChangeEvent értékre. Az IResourceChangeEvent szerződése korábban garantálta a munkaterület összes módosítása esetén az események következő sorrendezését:

  1. PRE_DELETE vagy PRE_CLOSE eseményértesítés, ha alkalmazható
  2. Végrehajtja a műveletet
  3. PRE_AUTO_BUILD eseményértesítés
  4. Ha az automatikus összeépítés be van kapcsolva, akkor hajtson végre munkaterület-összeépítést
  5. POST_AUTO_BUILD eseményértesítés
  6. POST_CHANGE eseményértesítés

Mivel az automatikus összeépítés háttérben fut, nincs garancia az AUTO_BUILD és POST_CHANGE esemény közötti ideiglenes kapcsolatra. Az Eclipse 3.0, verzióban a fenti struktúrában lévő 3-5. lépések eltávolításra kerültek a műveletből. Az eredményül kapott kép az alábbi módon néz ki:

  1. PRE_DELETE vagy PRE_CLOSE eseményértesítés, ha alkalmazható
  2. Végrehajtja a műveletet
  3. POST_CHANGE eseményértesítés

A platform rendszeres időközönként egy háttér munkaterület összeépítési műveletet hajt végre. Ez attól függetlenül végrehajtásra kerül, hogy az automatikus összeépítés be vagy ki van kapcsolva. Az összeépítés pontos időzítése nem kerül megadásra. Az összeépítési művelet struktúrája az alábbi módon fog kinézni:

  1. PRE_BUILD eseményértesítés (PRE_BUILD a PRE_AUTO_BUILD új neve)
  2. Ha az automatikus összeépítés be van kapcsolva, akkor hajtson végre munkaterület-összeépítést
  3. POST_BUILD eseményértesítés (a POST_BUILD a POST_AUTO_BUILD új neve)
  4. POST_CHANGE eseményértesítés

Az automatikus összeépítés figyelők által kapott változások referenciapontja különbözik a módosítás utáni figyelőkétől. Az összeépítés-figyelők az utolsó összeépítési művelet befejezése óta történt összes módosításról értesítést kapnak. A módosítás utálni figyelők egy változást kapnak, amely az utolsó módosítás utáni értesítés óta történt módosításokat írja le. Ez az új struktúra az erőforrásmódosítás-figyelők három jellemzőjét megtartja, amely az Eclipse 1.0 verzió óta igaz:

Néhány fontos különbség van ebben a megközelítésben. Az Eclipse 3.0 előtti verziókban az automatikus összeépítés-figyelők mindig a POST_CHANGE figyelők előtt kerülnek meghívásra. Ezen okból az automatikus összeépítés-figyelők által kapott változás mindig a POST_CHANGE figyelő által kapott változás részhalmaza. A viszony alapvetően fordított. Az automatikus összeépítés-figyelők által kapott változás a POST_CHANGE figyelők számára biztosított összes változás szuperszetje. Ahogy korábban is, az automatikus összeépítés-figyelők módosíthatják a munkaterületet, a módosítás utáni figyelők pedig nem.

A továbbiaknak nem igaz, hogy a munkaterület-módosítási művelet végrehajtásakor az AUTO_BUILD eseményfigyelők értesítést kapnak. Az erőforrásmódosítás-figyelőket az IWorkspace.addResourceChangeListener(IResourceChangeListener) elemhez regisztráló ügyfélkódra ez a változás valószínűleg nincs hatással, mivel az AUTO_BUILD eseményekről ezek a figyelők nem kaptak jelentést. Azon ügyfeleket, amelyek az IWorkspace.addResourceChangeListener(IResourceChangeListener,int) metódust használják, és AUTO_BUILD eseményeket tartalmazó eseménymaszkot adnak meg, ezen módosítás valószínűleg megszakítja, ha feltételezéseik vannak az automatikus összeépítés-figyelők futtatásának idejével vagy a futtatott szállakkal kapcsolatban. Ha az automatikus összeépítés-figyelő például frissíti a tartománymodellt, hogy tükrözze a munkaterület módosításait, akkor előfordulhat, hogy a frissítés nem történik meg, amikor a munkaterület-módosítási művelet visszatér. Ez nem ér semmit, mivel csak az UI szintű kód befolyásolható ily módon. Az alkalmazás programozási felületen keresztül meghívott magszintű kód meghívható az IWorkspaceRunnable hatókörében, így sosem lehet biztosan tudni az erőforrásmódosítás-figyelők meghívásának idejét. Ennek kiküszöbölése érdekében az összeépítés-figyelők helyett érdemes az POST_CHANGE elemet használni, ha a művelet befejezése előtt értesítésnek kell érkeznie.

22. Köztes értesítések a munkaterület-műveletek során

A továbbiakban nem garantálható, hogy az IWorkspaceRunnable dinamikus terjedelmében történő erőforrás-módosítások kötegelésre kerüljenek egy értesítésben. Ez a mechanizmus továbbra is használható a kötegelési módosításokhoz a szükségtelen összeépítések és értesítések elkerüléséhez, de a Platform dönthet úgy, hogy a működés során értesítést küld. Ez az API-szerződés várhatóan nem jelent lényeges változást a meglévő ügyfelek számára. Ez megfelel annak, hogy a Platform eldönti, hogy a hosszan futó műveletek során az IWorkspace.checkpoint rendszeres időközönként kerüljön meghívásra. Ezen módosítás oka, hogy egyszerre több szál módosíthatja a munkaterületet. Ha egy szál befejezte a munkaterület módosítását, akkor egy értesítésre van szükség a válaszkészség-problémák megakadályozása érdekében abban az esetben is, ha a másik művelet még nem befejeződött be. Ezen változtatás segítségével a felhasználók a művelet befejezése előtt elkezdhetnek egy erőforráshalmazon dolgozni. A felhasználó például böngészheti a végső ellenőrzési fázisban lévő projekt fájljait. Az új IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) metódus rendelkezik egy elhagyható jelzővel - AVOID_UPDATE -, amelyet a műveletek tippként használhatnak a platformhoz annak megadásához, hogy szükség van-e rendszeres időközönkénti frissítésre.

23. URL folyamkezelő-kiterjesztések

Befolyásolt elemek: Az org.eclipse.core.runtime.urlHandlers kiterjesztési ponthoz kiterjesztéseket közreadó bedolgozók.

Leírás: Az org.eclipse.core.runtime.urlHandlers kiterjesztési pont szerződése módosult, hogy az OSGi által biztosított URL folyamkezelő (URL Stream Handler) szolgáltatást használja. Az OSGi támogatás magasabb rendű, mint az Eclipse 2.1 verzióé, és megfelelően kezeli a dinamikus kezelőket. A Java URL kezelő mechanizmus különböző tervezési problémái miatt az OSGi kezelőszolgáltatáshoz bejegyzett URLStreamHandlers kezelőnek meg kell valósítani az org.osgi.service.url.URLStreamHandlerService szolgáltatást.

Szükséges tevékenység: Korábban az osztálykezelőknek meg kellett valósítaniuk a java.net.URLStreamHandler kezelőt, és ki kellett terjeszteniük az urlHandlers kiterjesztési pontot. A kiterjesztési pont a továbbiakban nem támogatott, és a kezelőt frissíteni kell az org.osgi.service.url.URLStreamHandlerService felület megvalósításához. Az OSGi keretrendszer egy absztrakt alapú osztályt biztosít (org.osgi.service.url.AbstractURLStreamHandlerService), amelyhez egyszerűen létrehozhatók alosztályok ezen szerep betöltése érdekében.

Ahelyett, hogy a kiterjesztési pontot a kezelő segítségével bejegyeznék, a bedolgozóknak ezt a kezelő szolgáltatásként bejegyzésével kell megvalósítaniuk. Például:

    Hashtable properties = new Hashtable(1);
    properties.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] {MyHandler.PROTOCOL});
    String serviceClass = URLStreamHandlerService.class.getName();
    context.registerService(serviceClass, new MyHandler(), properties);

24. Osztálybetöltési sorrend

Befolyásolt elemek: Más bedolgozók által szintén biztosított csomagokat szolgáltató bedolgozók. Ez a változás nagyon korlátozott számú bedolgozót értint, és ezen hatások egy része valójában előnyös (lásd alább).

Leírás: Az Eclipse 2.x verzióban az osztálybetöltők az alábbi sorrendben keresik az osztályokat: megnézik (1) a szülő osztálybetöltőt (gyakorlatban ez a Java rendszerbetöltő), majd (2) a saját osztályútvonal-tartalmát, és végül (3) az összes előfeltételt a megadott sorrendben. Az OSGi optimalizálást nyújt ehhez a modellhez. Ebben a megközelítésben az osztálybetöltő megnézi a (1) szülő osztálybetöltőt (valójában a Java osztálybetöltő), aztán vagy (2a) egy előfeltételt, amely kiegészíti az osztályt a lekérdezendő csomagban (2b) és az osztályútvonal-bejegyzéseket a kívánt osztályhoz.

Az osztálybetöltő az importált és szükséges csomagok alapján meghatározza, hogy önmagát vagy az előfeltéteket nézze meg. Ezek az információk a bedolgozó tartalmából származnak a hagyományos, és közvetlenül vannak megadva az explicit OSGi kötegleíróval rendelkező bedolgozók esetén. Minden esetben "a priori" tudjuk, hogy mely osztálybetöltők mely csomagokhoz biztosítják az osztályokat. Ez teljesítményjavulást eredményez valamint egy megoldást arra a bosszantó problémára, hogy több előfeltétel van megadva ugyanahhoz az osztályhoz.

Vegyük például a Xerces és Xalan esetét. Mindkettő tartalmaz az org.xml csomagokból származó különböző osztályokat. Az első megközelítés segítségével a Xerces és Xalan bedolgozó ezen osztályok saját másolatait látná. Mivel ezeknek a bedolgozóknak kommunikálniuk kell, ClassCastExceptions kivétel történik. A második megközelítéssel a két bedolgozó egyike lát csak másodpéldány-osztályokat, és mindkét bedolgozó ugyanazt a másolatot látja.

Szükséges tevékenység: A szükséges tevékenység a használatleírás részleteitől függ. Az érintett fejlesztőknek át kell tekinteniük az osztályútvonalat és fel kell oldaniuk az esetlegesen fellépő konfliktust.

25. Az osztálybetöltő védelmi tartomány nincs beállítva

Befolyásolt elem: A bedolgozók, amelyek azt várják, hogy az osztálybetöltőjük védelmi tartománya mindig be legyen állítva.

Leírás: Az Eclipse 2.1 bedolgozó osztálybetöltői a java.security.SecureClassloaderek voltak, és a védelmi tartomány mindig be volt állítva. Az Eclipse 3.0 verzióban az osztálybetöltők nem terjesztik ki a SecureClassloadert, és csak akkor kapcsolják be a védelmi tartományt, ha a Java biztonság be van kapcsolva (normál esetben nem).

Szükséges tevékenység: A szükséges tevékenység a szituációtól függ, amelyben a bedolgozó a védelmi tartományt használja.

26. PluginModel objektum átalakítása

Befolyásolt elem: A bedolgozók, amelyek átalakítják az org.eclipse.core.runtime.IPlugin* típusú objektumokat a org.eclipse.core.runtime.model.Plugin*Model típusúra. Ezen felületek és a modellosztályok közötti kapcsolat nincs megadva az Eclipse 2.1 alkalmazás programozási felületen, és explicit módon hívjuk meg ezt a módosítást, amikor olyan bedolgozópéldányokat találtuk, amelyek a 2.1 megvalósításban erre a kapcsolatra épülnek.

Leírás: Az Eclipse API egy felületsorozatot (például IPluginDescriptor), valamint a bedolgozókhoz vagy bedolgozó-nyilvántartáshoz kapcsolódó úgynevezett "modell" osztályokat (például PluginDescriptorModel) biztosít. Az Eclipse 2.1 megvalósításban a modellosztályok valósítják meg az érintett felületeket. Az új OSGi alapú futási környezetben a bedolgozó-nyilvántartás jelentősen átdolgozásra került annak érdekében, hogy szét lehessen választani az osztálybetöltést, a bedolgozó előfeltételeit, valamint a kiterjesztés és kiterjesztési pont szempontokat. Az Eclipse 3.0 futási környezet nem tudja fenntartani a 2.1 verzióban meglévő megvalósítási kapcsolatot.

Szükséges tevékenység: Erre a nem API kapcsolatra épülő bedolgozóknak a használatleírásnak megfelelően át kell dolgozniuk a kódot. Ezzel kapcsolatos további információkat a dokumentum javasolt módosítások része, valamint a kapcsolódó osztályok és metódusok Javadoc dokumentuma tartalmaz.

27. Az ILibrary megvalósítása befejezetlen

Befolyásolt elemek: Az org.eclipse.core.runtime.ILibrary elemet használó bedolgozókra.

Leírás: Az új futási környezet az osztályútvonal-bejegyzéseket másképp tartja karban, mint az Eclipse, és a két módszer inkomptabilis. Ennek eredményképp a kompatibilitási réteg nem tudja megfelelően modellezni az alapul szolgáló OSGi struktúrákat ILibrary objektumokként. A futási környezet kompatibilitás-támogatása létrehoz ILibrary objektumokat, de a könyvtár elérési útjának kivételével mindenhez az alapértelmezett értékeket kell feltételezni.

Szükséges tevékenység: Az ILibrary felhasználóinak meg kell fontolniuk a szükséges fejlécértékek (például Bundle-Classpath) megfelelő kötegből elérését (lásd Bundle.getHeaders()) és a ManifestElement súgóosztály használtát a bejegyzések értelmezéséhez. Részletes információkat a Javadoc tartalmaz.

28 Érvénytelen feltételezések az URL címek formátumát illetően

Befolyásolt elemek: A bedolgozók, amelyek a telepítési struktúrával, a hellyel és a helyi fájlrendszer-elrendezéssel kapcsolatos feltételezéseket tesznek.

Leírás: Az IPluginDescriptor.getInstallURL() és hasonló metódusok adott formátumú URL címet adnak vissza. Annak ellenére, hogy a formátum nincs megadva, a különböző bedolgozók feltételezéseket tesznek az aktuális megvalósítás alapján. Például lehet, hogy kapnak egy file: URL címet, meghívják az URL.getFile() metódust, majd a java.io.File kezelést használják az eredményen. Ez egy működő, de meglehetősen sérülékeny megközelítés. Ha a bedolgozó például a webkiszolgálóra van telepítve, akkor elképzelhető, hogy a http: formátumú URL cím kerül visszaadásra. Az új Eclipse 3.0 futási környezet rugalmasabb, és több lehetőséget biztosít a végrehajtás-konfigurációkhoz (például teljes bedolgozók fenntartása a JAR-fájlokban könyvtárakba szétosztás helyett). Ezért van az, hogy mialatt az új OSGi alapú futási környezet valójában nem szakítja meg a 2.1 alkalmazás programozási felületet, és több esetet veszélyeztet, amelyben az aktuális bedolgozókkal kapcsolatos feltételezések érvénytelenek voltak.

Szükséges tevékenység: A bedolgozóíróknak ellenőrizniük kell, hogy az információk, amelyekhez hozzá kell férniük, elérhetők-e a getResource() segítségével (és benne van az osztályútvonalban), vagy az érintett alkalmazás programozási felületet kell használni a bedolgozó tartalmának eléréshez (például Bundle.getEntry(String)).

29. Áthelyezett/törölt BootLoader metódusok

Befolyásolt elemek: A nem bedolgozó kód, amely adott metódusokat hív meg az org.eclipse.core.boot.BootLoader osztályból.

Leírás: A statikus BootLoader.startup(), shutdown() és run() metódusok átkerültek az org.eclipse.core.runtime.adaptor.EclipseStarter elembe, amely az OSGi keretrendszer része. Ez az API a felület a startup.jar fájlban lévő main() és az OSGi keretrendszer/Eclipse futási környezet között. A futási környezet átstrukturálása nem engedélyezi, hogy ezek a metódusok a BootLoaderen maradjanak. A régi BootLoader osztály most a futási kompatibilitási rétegben található és elavult, és az áthelyezett metódusok lerövidítésre kerültek, hogy ne tegyenek semmit.

A régi BootLoader.getRunnable() metódusnak nincs helyettesítője, mivel a futási környezet a továbbiakban nem támogatja az egyedi alkalmazások beszerzését. A felhasználóknak a platform elindításakor jelezniük kell a számukra érdekes alkalmazást.

Szükséges tevékenység: Általában ezt az alkalmazás programozási felületet csak néhány személy használja (Eclipse bedolgozóból nem használható). Ilyen ritka esetben a kódot adaptálni kell, hogy a megfelelő metódusokat használja az EclipseStarteren.

30. A bedolgozóexportálás automatikusan nem foglalja magában a bedolgozók JAR fájljait

Befolyásolt elemek: Az összes bedolgozó.

Leírás: Az Eclipse 2.1 verzióban a bedolgozó build.properties fájl bin.includes sorának nem kell tartalmaznia a plugin.xml fájl függvénytár-deklarációjából származó JAR fájlok listáját; ezek a JAR-fájlok ingyenesen kerültek hozzáadásra. Az Eclipse 3.0 verzióban a build.properties bin.includes részben található fájlok listája kimerítő lista, és az összes fájlt tartalmaznia kell, amelyet a bedolgozófejlesztők bele kívánnak rakni a bedolgozóba összeépítéskor és exportáláskor.

Szükséges tevékenység: Győződjön meg róla, hogy a build.properties fájl bin.includes sora tartalmazza a plugin.xml fájlban felsorolt összes JAR-fájlt.

31. Futási API újbóli exportálása

Befolyásolt elemek: A bedolgozók, amelyek kiteszik a módosított futási alkalmazás programozási felületről származó elemeket tartalmazó alkalmazás programozási felületet.

Leírás: A különböző bedolgozók a futási alkalmazás programozási felületről származó elemeket tartalmazó alkalmazás programozási felületet tesznek ki. Az Eclipse 3.0 futási környezet itt kiemelt módosításaival az ügyfél-bedolgozóknak újból ki kell értékelniük a futási API saját alkalmazás programozási felületen alkalmazását.

Szükséges tevékenység: Ez a szituáció meglehetősen ritka, mivel az Eclipse futási API nagyon kis része lett csak módosítva. A szituációtól függően előfordulhat, hogy az ügyfeleknek módosítaniuk kell az alkalmazás programozási felületet vagy továbbra is a kompatibilitási rétegre kell támaszkodniuk.

32. Bedolgozóelemzési metódusok a platformon

Befolyásolt elemek: Az org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) elemet használó bedolgozók

Leírás: Az org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) metódus áthelyezésre került. A Factory argumentumhoz társított API áthelyezésre került az org.eclipse.core.runtime bedolgozóból az org.eclipse.core.runtime.compatibility bedolgozóba (amely a futási bedolgozótól függ). Ennek eredményeképp az elemzési metódus is eltávolításra került.

Szükséges tevékenység: A metódus felhasználóinak ugyanazt a metódust kell használniuk az org.eclipse.core.runtime.model.PluginRegistryModel elemen.

33. A töredékek által biztosított bedolgozó-függvénytárak

Befolyásolt elemek: Bedolgozók, amelyek kódot adnak meg az osztályútvonalon, de nem szolgáltatják ezt a kódot (a JAR-fájlt például a töredék szolgáltatja; azaz az org.eclipse.swt bedolgozó).

Leírás: Az új futási környezetnek a háttérben kell átalakítani a plug.xml fájlokat manifest.mf fájllá. Ez egy egyenes mechanikus átalakítás segítségével, valamint a bedolgozó által felsorolt és szolgáltatott jar fájlok elemzésével történik. Abban az esetben, ha a bedolgozó az osztályútvonalon megad egy jar fájlt, de nem biztosítja a jar fájlt, akkor nincs elemzendő kód, és a bedolgozóátalakító nem tud megfelelő manifest.mf fájlt előállítani.

Szükséges tevékenység: Az ilyen bedolgozók szolgáltatóit módosítani kell, hogy magában a bedolgozóban biztosítsák a megfelelő jar fájl, vagy maguknak kell létrehozni/fenntartani egy META-INF/MANIFEST.MF fájlt a bedolgozóhoz. Jellemzően a PDE segítségével kérhető le a kezdeti leírófájl, majd hozzáadható a megfelelő Provide-Package header részhez.

34. Összeépítési parancsfájlok módosítása

Befolyásolt elemek: Parancsfájlok (például Ant build.xml fájlok), amelyek futási környezettel kapcsolatos jar fájlokat és osztálykönyvtárakat tartalmazó osztályútvonalakat adnak meg.

Leírás: Az új futási környezet számos új bedolgozót és jar fájlt tartalmaz. Ezek bevezetését a futási környezet konfigurálható részekké alakítása teszi kötelezővé. A legtöbb futási helyzetben ezek a változások átlátszók. Ha egyéni build.xml (vagy hasonló) parancsfájlokkal rendelkezik, amelyek éppen az org.eclipse.core.runtime elemhez fordítják le a kódot, akkor a megfelelő működés érdekében frissíteni kel őket. Egy jellemző parancsfájl egy osztályútvonal-bejegyzést tartalmaz a <javac> feladatban, amely az org.eclipse.core.runtime bedolgozóra hivatkozik az alábbi módon:

    ../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar

A futási bedolgozó továbbra is tartalmazza az eredeti futási kód nagy részét. A futási környezet kizárólag kompatibilitási célokat szolgáló különböző részeit a kompatibilitás bedolgozó tartalmazza (org.eclispe.core.runtime.compatibility). Az új futási kód nagy részét a bedolgozók gyűjteménye tartalmazza (org.eclipse.osgi.*).

Szükséges tevékenység: A fordítási hibák elkerülése érdekében a fejlesztőknek szükség szerint hozzá kell adniuk az alábbi bejegyzéseket. Az alábbi lista a szolgáltatott jar-fájlok teljes halmazát biztosítja, de egy jellemző alkalmazáshoz fordítási időben ennek csak egy részhalmaza szükséges az osztályútvonalon. A /bin könyvtárak megadása általában tetszés szerinti. Az itt megadott bejegyzések a szolgáltató bedolgozó által megadott logikai csoportosításban láthatók:

Az alábbi jar fájlokra speciális esetben van szükség:

Az ilyen parancsfájlok frissítésekor az org.eclipse.core.boot hivatkozásait is el kell távolítani. Ez a bedolgozó elavult és már nem tartalmaz kódot. Maradhatnak bejegyzések az osztályútvonalon, de ezek nem szolgálnak célt, és el kell távolítani őket. Ügyeljen rá, hogy eltávolításra kerüljenek az alábbiak:

    ../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar

35. PDE összeépítési Ant feladat módosításai

Befolyásolt elemek: Az eclipse.buildScript feladatot használó parancsfájlok (például Ant build.xml fájlok).

Leírás: A PDE Build egy új tulajdonságot vezetett be az eclipse.buildScript feladathoz a bedolgozók összeépítési parancsfájljainak előállításához. Ezt az új OSGi alapú futási környezet bevezetése tette kötelezővé.

Szükséges tevékenység: Ha az Eclipse 3.0 segítségével egy 2.1 alapú terméket kíván létrehozni, akkor az eclipse.buildScript elemben vezesse be a "buildingOSGi" tulajdonságot és állítsa hamis értékre. Például:

<eclipse.buildScript ... buildingOSGi="false"/>

36. Az eclipse.build Ant feladat módosításai

Befolyásolt elemek: Az eclipse.buildScript feladatot használó parancsfájlok (például Ant build.xml fájlok).

Leírás: A PDE Build egy új tulajdonságot vezetett be az eclipse.buildScript feladathoz a bedolgozók összeépítési parancsfájljainak előállításához. Ezt az új OSGi alapú futási környezet bevezetése tette kötelezővé.

Szükséges tevékenység: Ha az Eclipse 3.0 segítségével egy 2.1 alapú terméket kíván létrehozni, akkor az eclipse.buildScript elemben vezesse be a "buildingOSGi" tulajdonságot és állítsa hamis értékre. Például:

<eclipse.buildScript ... buildingOSGi="false"/>

37. Az eclipse.fetch Ant feladat módosításai

Befolyásolt elemek: Az eclipse.buildScript feladatot használó parancsfájlok (például Ant build.xml fájlok).

Leírás: A PDE Build megváltoztatta az eclipse.fetch feladat viselkedését az eclipse összeépítésének leegyszerűsítése érdekében egy automatizált összeépítési stílusban. Az elemek stílus jelenleg egyszerre csak egy bejegyzést támogat, és a scriptName mindig figyelmen kívül marad.

Szükséges tevékenység: Ha az eclipse.fetch hívás "elements" címkéjében bejegyzések listája található, akkor terjessze ki őket számos eclipse.fetch hívásra. Ha beállítja a scriptName elemet, akkor ne feledje el, hogy az előállított lehívó parancsfájl neve mindig "fetch_{elementId}". Például:

<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>

címből a következő lesz:

<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../>
<eclipse.fetch elements="feature@org.eclipse.platform" .../>

38. Az install.ini helyettesítése

Az install.ini fájl a továbbiakban nincs megadva. Ennek helyén az új config.ini fájl található a konfiguráció alkönyvtárban. A termékeknek, amelyek az install.ini fájl segítségével adnak meg egy elsődleges szolgáltatást (például arculatinformációk biztosításához), a config.ini fájlt kell módosítaniuk. Az új fájlnéven felül a kulcsok nevei is módosultak.

A 2.1 verzióban a feature.default.id kulcs értékét az új eclipse.product kulcs értékeként kell beállítani. Az eclipse.application elemet "org.eclipse.ui.ide.workbench" értékre kell állítani.

A 2.1 verzióban a programindító ablak képe mindig az arculatkészítő bedolgozó könyvtárában lévő splash.bmp volt. A 3.0 verzióban a programindító ablak képének helyét a config.ini fájlban lévő osgi.splashPath kulcs adja meg explicit módon.