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.
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.
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 |
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.
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.
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:
org.eclipse.core.runtime.jobs.ILock
.
Az ILock
előnye az általános zárolásokkal szemben, hogy a
syncExec
végrehajtásakor automatikusan átkerülnek az UI
szálba, és a holtpont-felismerési támogatás be van építve a
megvalósításba, amely naplózza és feloldja a holtpontokat.Display.asyncExec
), amely teljes egészében egy UI szálban
kerül feldolgozásra.java.lang.String
és
org.eclipse.core.runtime.IPath
, szálbiztonságossá teszi. Az
állandó objektumok előnye a rendkívül gyors olvasási hozzáférés, a
módosítás extra munkájának költségével.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".)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.
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.
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:
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.
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.
Ú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.
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.
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.
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:
Az org.eclipse.ui.texteditor.AbstractTextEditor módosításai:
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
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:
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
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.
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.
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.
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.
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.
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.
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.
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:
PRE_DELETE
vagy PRE_CLOSE
eseményértesítés, ha alkalmazhatóPRE_AUTO_BUILD
eseményértesítésPOST_AUTO_BUILD
eseményértesítésPOST_CHANGE
eseményértesítésMivel 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:
PRE_DELETE
vagy PRE_CLOSE
eseményértesítés, ha alkalmazhatóPOST_CHANGE
eseményértesítésA 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:
PRE_BUILD
eseményértesítés (PRE_BUILD
a
PRE_AUTO_BUILD új neve)
POST_BUILD
eseményértesítés (a POST_BUILD
a POST_AUTO_BUILD új neve)
POST_CHANGE
eseményértesítésAz 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:
POST_CHANGE
figyelők a bejegyzett idő alatt történt
összes erőforrásmódosításról értesítést kapnak. Ez magában foglalja az
összeépítők és más figyelők által végzett módosításokat is.PRE_AUTO_BUILD
figyelők az összes
erőforrásmódosításról értesítést kapnak az összeépítők és
erőforrásmódosítás-figyelők által végzett módosítások kivételével.POST_AUTO_BUILD
figyelők az összes
erőforrás-módosításról értesítést kapnak a más
POST_AUTO_BUILD
figyelők által végzett módosítások
kivételével.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.
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.
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);
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.
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.
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.
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.
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)
).
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.
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.
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.
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.
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.
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
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"/>
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"/>
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" .../>
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.