A 3.0 mechanizmusok és alkalmazás programozási felületek átvételekor szükséges módosítások

Ez a rész leírja a szükséges módosításokat, ha a 2.1 bedolgozót módosítani kívánja, hogy elfogadja a 3.0 mechanizmusokat és alkalmazás programozási felületeket.

Az org.eclipse.core.runtime.compatibility feladása

Az Eclipse 3.0 futási környezet jelentősen különbözik. Az alapul szolgáló megvalósítás az OSGi keretrendszer-specifikációra épül. Az Eclipse 3.0 futási környezet tartalmaz egy kompatibilitási réteget (az org.eclipse.core.runtime.compatibility bedolgozóban), amely karbantartja a 2.1 alkalmazás programozási felületeket. A jobb teljesítményben és további funkciókban érdekelt bedolgozófejlesztőknek meg kell fontolniuk a 3.0 alkalmazás programozási felületek alkalmazását és a kompatibilitási réteg függőség megszüntetését. A kompatibilitási kód három helyen jelenik meg:

Az alábbi szöveg részletes információkat biztosít azzal kapcsolatban, hogy mely osztályok és metódusok vannak jelen kompatibilitási okokból, valamint a bedolgozó frissítésének módját mutatja be.

Bedolgozók és kötegek

Az Eclipse futási környezet két részre lett bontva; az osztálybetöltés és az előfeltétel-kezelés, valamint a kiterjesztés/kiterjesztési pont kezelés. Ezen felosztás segítségével az OSGi keretrendszer-specifikáció természetesen/zökkenőmentesen alkalmazható az osztálybetöltéshez és az előfeltétel-kezeléshez. Ez számos új képességet tesz lehetővé a futási környezetben a bedolgozó dinamikus telepítési/frissítési/eltávolítási lehetőségétől a biztonságig és jobb konfigurálhatóságig.

Továbbra is bedolgozókról beszélünk, de az új futási környezetben a bedolgozó valójában egy köteg, néhány kiterjesztés és kiterjesztési pont. A köteg kifejezést az OSGi keretrendszer-specifikáció használja: típusok valamint erőforrások gyűjteményére utal, és kötegen belüli előfeltétel-információkhoz vannak társítva. A kiterjesztésnyilvántartás a bedolgozónyilvántartás új formája, és csak a kiterjesztés valamint a kiterjesztési pont információkat részletezi. A kiterjesztésnyilvántartási API nagyjából megegyezik az érintett bedolgozónyilvántartás alkalmazás programozási felülettel (további információkat a Nyilvántartások rész tartalmaz).

Az Eclipse 2.x futási környezetben a bedolgozóobjektum számos szereppel és felelőséggel rendelkezik:

Az Eclipse 3.0 futási környezet képben ezek a szerepek és felelősségek külön objektumokra lettek bontva.

Köteg
A köteg a modularitás OSGi egysége. Kötegenként egy osztálybetöltő található, és Eclipse-szerű kötegen belüli osztálybetöltési függőségi gráfok hozhatók létre. A kötegek életciklussal rendelkeznek, amely az indítástól a leállításig tart, és az OSGi keretrendszer üzenetszórással elküldi a kapcsolódó eseményeket (például telepítés, feloldás, indítás, leállítás, eltávolítás,...) az érdekelt résztvevők számára. Az Eclipse Bedolgozó osztállyal ellentétben az OSGi Köteg osztály nem terjeszthető ki. Azaz a fejlesztők nem adhatnak meg saját kötegosztályokat.
BundleActivator
A BundleActivator az OSGi keretrendszer által megadott felület. Minden köteg megadhat egy kötegaktiváló-osztályt, ahhoz hasonlóan, ahogy a bedolgozó Bedolgozó osztályt adhat meg. A megadott osztályt a keretrendszer példányosította, és megvalósítja a start() illetve stop() életciklus-feldolgozást. Jelentős eltérés van az életciklus feldolgozásában. Az Eclipse szoftverben általános (habár nem ajánlott), hogy a Bedolgozó osztályok az inicializálást és regisztrálást is végrehajtják. OSGi-ben az aktiválóknak csak a regisztrációt kell végrehajtaniuk. Ha az inicializálás (vagy egyéb más munka) nagy része a BundleActivator.start() metódusban történik, akkor ez veszélyezteti a rendszer életképességét.
BundleContext
A BundleContext az OSGi mechanizmus az általános rendszerfunkció egyedi kötegekre kitételére. Minden köteg egyedi és privát BundleContext példánnyal rendelkezik, amely segítségével elérhetik a rendszerfunkciókat (például getBundles() a rendszer összes kötegének felderítéséhez).
Bedolgozó
Az új Bedolgozó nagyon hasonlít az eredeti Eclipse Bedolgozó osztályra az alábbi kivétellel: a futási környezetnek már nincs szüksége a Bedolgozó objektumokra, és nem is kezeli őket, a különböző metódusok pedig elavultak. Ez alapvetően egy kényelmes mechanizmus hasznos funkciók és mechanizmusok biztosításához, de a továbbiakban egyáltalán nincs rá szükség. Az itt biztosított funkciók nagy része a futási környezet Platform osztályában is elérhető.

A bedolgozó a BundleActivator aktiválót is megvalósítja. Ez annak kényelmét ismeri el, hogy egy központi objektum ábrázolja a bedolgozó életciklusát és szemantikáját. Ez nem szentesíti az adatstruktúrák mohó inicializálását, amely manapság a bedolgozókban általános. Nem hangsúlyozhatjuk eléggé, hogy a bedolgozók aktiválhatók, ha néhány másik bedolgozóban az osztály ellenőrzése során egy periféria osztályra hivatkoztak. Azaz a bedolgozók aktiválása nem jelenti szükségszerűen azt, hogy funkcióra szükség van. Tetszőlegesen egy másik BundleActivator osztály is megadható, de a kötegaktiváló teljesen el is távolítható.

A 2.x Bedolgozó osztály Eclipse 3.0 verzióra átírásának szükséges lépései a használt osztálytól függenek. Ahogy fent említettük, a legtöbb indítási életciklus-feladat az alábbi kategóriák egyikébe esik:

Inicializálás
Az adatstruktúra- és modellinicializálás gyakran a Plugin.startup() fájlban történik. A természetes/nyilvánvaló leképezés hatására a munka a BundleActivator.start() metódusban zajlana, amely a funkciót a Bedolgozón hagyja. Ez nem javasolt. 2.x bedolgozókhoz hasonlóan a 3.0 bedolgozók/kötegek számos különböző ok miatt elindíthatók különböző körülmények között.
Egy Eclipse 2.0 verzióból származó tényleges példa megvilágítja ezt az esetet. Volt egy nagy modellt inicializáló bedolgozó, amelyhez be kell tölteni a kód néhány 11 MB-os részét és számos megabyte-nyi adatot. Általános használateset volt, hogy ez a bedolgozó aktiválásra került annak felderítéséhez, hogy a navigátorban megjelenő projektikont fel kell díszíteni egy adott leírónyelvvel. Ehhez a teszthez a startup() metódusban nem kell inicializálást végrehajtani, de az összes használateset felhasználójának memóriát és időt kell áldoznia ehhez a mohó inicializáláshoz.
EGy alternatív megközelítés, ha az inicializálás egy klasszikus lusta stílusban történik. Ahelyett például, hogy a modellek a bedolgozó/köteg aktiválásakor kerülnének inicializálásra, ez akkor történik, amikor valóban szükség van rájuk (például egy központosított modellelérő-metódusban). Számos használatesetben ez nagyjából ugyanannyi időt jelent, de más szituációban ez a megközelítés késlelteti az inicializálást (talán korlátlanul). A 2.1 bedolgozók átírásakor érdemes egy kis időt szentelni a használandó inicializálási stratégia átgondolására.
Regisztráció
A bedolgozó indítása megfelelő időpont a figyelők, szolgáltatások, stb., bejegyzésére, valamint a háttérben futó feldolgozási szálak indítására (például egy socket figyelése). A Plugin.start() megfelelő hely lehet ennek végrehajtására. Hasznos lehet esetleg másik aktiváló esemény bekövetkezésig késleltetni (például adott funkció vagy adatelem használatáig).
Bedolgozó globális adatok
A Bedolgozó osztály továbbra is betöltheti ezt a szerepet. A fő probléma, hogy a Bedolgozó objektumok a rendszer által kezelt listán keresztül már nem érhetők el globálisan. Az Eclipse 2.x verzióban a bedolgozó-nyilvántartáson keresztül feltérképezhető a bedolgozó Bedolgozó objektuma. Ez már nem lehetséges. A legtöbb esetben ez a hozzáférési típus nem szükséges. A nyilvántartáson keresztül elért Bedolgozók jellemzően általános Bedolgozókként kerülnek felhasználásra tartomány-specifikus metódusok meghívása helyett. A megfelelő képességi szint a megfelelő Köteg objektumok kezelésével és hozzáférésével is elérhető.

Nyilvántartások és a bedolgozómodell

Az új futási környezetben el vannak különítve a bedolgozó végrehajtásához szükséges információk és struktúrák, amelyek a bedolgozó kiterjesztéseihez és kiterjesztési pontjaihoz kapcsolódnak. Az előbbieket az OSGi keretrendszer-specifikáció adja meg és kezeli. Az utóbbiak Eclipse-specifikus alapelvek, és az Eclipse futási kód adja meg őket. Az eredeti bedolgozó-nyilvántartás és a kapcsolódó objektumok fel lettek osztva OSGi kötegekre és egy Eclipse kiterjesztés-nyilvántartásra.

A végrehajtási specifikációt kezelő IPluginRegistry részei (például IPluginDescriptor, ILibrary, IPrequisite) elavultak, és a kiterjesztésekhez valamint kiterjesztési pontokhoz kapcsolódó további részek átkerültek az IExtensionRegistry nyilvántartásba. A bedolgozó nyilvántartáshoz egészként kapcsolódó úgynevezett modellobjektumok elavultak. Ezeket a típusokat a futási rendszer jelenítette meg és példányosította elsődlegesen az eszközkezelés - mint például a PDE - támogatása érdekében. Sajnos gyakran az az eset, hogy a szükséges információk szintje meghaladja a képességeket és érdekeltséget (például a plugin.xml elemek sorszámainak megjegyzése) és végül a futási környezet információk lehetséges ügyfeleinek karban kell tartaniuk a saját struktúrájukat.

Az új futási környezetben újból kiértékeltük a futási környezet által biztosított szolgáltatásokat és már csak azok biztosítottak, amelyek alapvető fontosságúak a futási környezet végrehajtáshoz vagy kivételesen nehéz ez mások számára. Ahogy fent említettük, a bedolgozó nyilvántartásmodell-objektumok elavultak, mivel rendelkeznek bedolgozóelemzési alkalmazás programozási felülettel. Az kiterjesztések nyilvántartás karbantartja az alapvető fontosságú kiterjesztéssel kapcsolatos információkat. Az új állapot (lásd: org.eclipse.osgi.service.resolver.State és egyéb ismerős elemek) struktúra ábrázolja és lehetővé teszi a lényeges végrehajtással kapcsolatos információk kezelését.

NL töredékstruktúra

Az Eclipse 3.0 verzióban az NL töredékstruktúra frissítésre került, hogy konzisztensebb legyen. Korábban a fájlok - mint például a plugin.properties - fordításairól feltételezték, hogy a töredékek által biztosított JAR fájlokban vannak. Mivel az eredeti fájlok az érintett gazdabedolgozó gyökerében találhatók, a lefordított fájlok egy konzisztensebb helyen találhatók, az NL töredékek gyökerében. Például:

  org.eclipse.ui.workbench.nl/
     fragment.xml
     plugin_fr.properties
     plugin_pt_BR.properties
     ...
     nl1.jar

Figyelje meg, hogy az nl1.jar fájl korábban tartalmazta a plugin.properties fordításait. Ezek a fájlok a töredék gyökerében találhatók, és a JAR tárolja a lefordítható erőforrások fordításait (például az osztálybetöltőn keresztül betöltött fájlok) a gazdabedolgozóban.

Természetesen az Eclipse 3.0 verzióban futó 2.1 gazdabedolgozók továbbra is támogatják az Eclipse 2.1 töredékstruktúrát. A 2.1 NL töredék nem használható 3.0 bedolgozón. A töredéket frissíteni kell az új struktúrához.

API módosítások áttekintés

org.eclipse.core.boot (org.eclipse.core.boot csomag)

A teljes org.eclipse.core.boot csomag elavult. A BootLoader összefésülésre került az org.eclipse.core.runtime.Platform elemmel, mivel a rendszerbetöltés és futási környezet közötti felosztásának a továbbiakban nincs értelme. Az org.eclipse.core.boot bedolgozó felosztásra, a teljes kód pedig áthelyezésre került az új futási környezetbe vagy a kompatibilitási rétegbe.

Az IPlatformConfiguration az Eclipse Telepítés/Frissítés összetevő által megadott típussal rendelkezik. A futási környezet újraszervezésével ezt a típust visszaküldhetjük jogos helyére. Ez az osztály lényegében változatlan, és újracsomagolásra került org.eclipse.update.configurator.IPlatformConfiguration elemként.

Az IPlatformRunnable átkerült az org.eclipse.core.runtime.IPlatformRunnable elembe.

IExtension és IExtensionPoint (org.eclipse.core.runtime csomag)

A getDeclaringPlugin() metódus (minden osztályon) egy felfelé mutató hivatkozást biztosít a bedolgozóhoz, amely megadja a kiterjesztési pont kiterjesztését (értelemszerűen). Az új nyilvántartásmodell szétválasztja a bedolgozók végrehajtási aspektusait a kiterjesztés/kiterjesztési pont aspektusoktól, és nem tartalmazza az IPluginDescriptors bedolgozót. Ezen API felhasználóinak meg kell fontolniuk az új getParentIdentifier() metódus használatát, amely az IExtension és IExtensionPoint elemen található meg.

ILibrary, IPluginDescriptor, IPluginRegistry és IPrerequisite (org.eclipse.core.runtime csomag)

Az eredeti futási környezetben a bedolgozó nyilvántartás egy teljes képet tart fenn a futási konfigurációról. Az Eclipse 3.0 verzióban ez a kép az OSGi keretrendszerre és a kiterjesztési nyilvántartásra is kiterjed. Ily módon ezek az osztályok elavultak. Az elavulási megjegyzések a kód frissítési módjával kapcsolatos részleteket tartalmaznak.

Platform és bedolgozó (org.eclipse.core.runtime csomag)

Az új futási környezetben a Bedolgozó objektumokat a futási környezet már nem kezeli, így a Platformon keresztül általánosan nem érhetők el. Ehhez hasonlóan a bedolgozónyilvántartás már nem létezik és nem biztosít hozzáférést a bedolgozóleírókhoz. Megfelelő helyettesítőmetódusok állnak rendelkezésre, amelyek részletes leírása ezen osztályok elavult metódusainak Javadoc dokumentumaiban találhatók.

org.eclipse.core.runtime.model (org.eclipse.core.runtime.model csomag)

A csomag összes típusa elavult. További információkat a nyilvántartások leírása tartalmaz.

IWorkspaceRunnable és IWorkspace.run (org.eclipse.core.resources csomag)

Az IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) metódus ügyfeleinek át kell tekinteniük a metódus használatát, és meg kell fontolniuk a nagyobb funkciógazdagságú metódusok használatát IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). A régi IWorkspace.run metódus az IWorkspaceRunnable időtartama alatt egy zárolást szerez a teljes munkaterületre. Ez azt jelenti, hogy a metódussal végzett művelet nem futhat párhuzamosan más műveletekkel, amelyek a munkaterületet módosítják. Az Eclipse 3.0 verzióban számos hosszan futó művelet került át a háttérszálakba, így a műveletek közötti konfliktusok valószínűsége nagymértékben növekedett. Ha egy hosszan futó háttérművelet egy modális előtérműveletet blokkol, akkor az UI blokkolásra kerül a háttérművelet befejeződésééig, vagy a műveletek egyikének törléséig.

A javasolt megoldás a régi IWorkspace.run metódusra mutató összes hivatkozás átkapcsolása, hogy az új metódust használják egy ütemezési szabályparaméterrel. Az ütemezési szabálynak a legfinomabban szabályozhatónak kell lennie, amely összefogja a művelet által végzett összes módosítás szabályait. Ha a művelet az ütemezési szabály hatókörén kívül eső erőforrást próbál módosítani, akkor futási kivétel történik. Az adott munkaterület-művelet által igényelt precíz ütemezési szabály nincs megadva, és az adott projekten telepített lerakatszolgáltatótól függően változhat. Az erőforrás-módosítási művelet ütemezési szabályának megszerezéséhez az IResourceRuleFactory gyárat kell használni. Ha kívánatos, akkor a MultiRule segítségével több erőforrásszabály is megadható, és a MultiRule.combine metódus segítségével kombinálhatók a különböző erőforrás-módosítási műveletek szabályai.

Ha nincs szükség zárolásra, akkor a null ütemezési szabálya használható. Ennek segítségével a futtatható fájl módosíthatja a munkaterület összes erőforrását, de nem akadályozza meg, hogy más szálak egyidejűleg szintén módosítsák a munkaterületet. A munkaterület egyszerű módosításához ez gyakran a legegyszerűbb és leginkább egyidejűség-támogató megoldás.

IWorkbenchPage (org.eclipse.ui csomag)

IEditorDescriptor (org.eclipse.ui csomag)

ISharedImages (org.eclipse.ui csomag)

IWorkbenchActionConstants (org.eclipse.ui csomag)

IWorkbenchPreferenceConstants (org.eclipse.ui csomag)

IExportWizard (org.eclipse.ui csomag)

IImportWizard (org.eclipse.ui csomag)

INewWizard (org.eclipse.ui csomag)

WorkbenchHelp (org.eclipse.ui.help csomag)

IHelp (org.eclipse.help csomag)

ITextEditorActionConstants (org.eclipse.ui.texteditor csomag)

IAbstractTextEditorHelpContextIds (org.eclipse.ui.texteditor csomag)

BasicTextEditorActionContributor (org.eclipse.ui.texteditor csomag)

TextEditorActionContributor (org.eclipse.ui.editors.text csomag)

annotationTypes kiterjesztési pont (org.eclipse.ui.editors bedolgozó)

Itt a feljegyzéstípus explicit megjegyzése található. Lásd: Annotation.getType() és Annotation.setType(). A feljegyzés típusa az élettartama során változhat. Egy kiterjesztési pont került hozzáadásra a feljegyzéstípus deklarációjához: "org.eclipse.ui.editors.annotationTypes". A feljegyzéstípusnak van neve, és deklarálható egy másik megadott feljegyzési típus altípusaként. A feljegyzéstípus-deklaráció a "markerType" és "markerSeverity" attribútumokat is használhatja annak megadásához, hogy az adott típusú jelzőket és fontosságot a szövegszerkesztőnek egy adott feljegyzéstípus feljegyzéseiként kell megadni. Az "org.eclipse.ui.editors.markerAnnotationSpecification" "markerType" és "markerSeverity" attribútumait a továbbiakban nem szabad használni. Ezért a jelzőfeljegyzés-specifikációk a jelzőktől függetlenek lesznek, és a név félrevezető. A rendszer a visszamenőleges kompatibilitás biztosítása érdekében megtartja a nevet.

Az AbstractMarkerAnnotationModel alosztályainak példányai a jelzőkhöz létrehozott feljegyzésekhez automatikusan észlelik és beállítják a megfelelő feljegyzéstípust. Egy adott jelző vagy egy adott markerType és markerSeverity pár feljegyzéstípusa az org.eclipse.ui.texteditor.AnnotationTypeLookup segítségével programozási eljárással lekérhető.

A feljegyzéstípusok hierarchiájának elérését az IAnnotationAccessExtension biztosítja. Egy adott feljegyzéstípushoz lekérhető a szupertípusok lánca, és ellenőrizhető, hogy a feljegyzéstípus egy másik feljegyzéstípus altípusa-e. A DefaultMarkerAnnotationAccess megvalósítja ezt a felület.

markerAnnotationSpecification kiterjesztési pont (org.eclipse.ui.editors bedolgozó)

A feljegyzéstípus a kulcs, amellyel a társított jelzőfeljegyzés-specifikáció kikereshető. Mivel a feljegyzéstípus kiterjeszthet másik kiterjesztéstípust, implicit kapcsolat van a jelzőfeljegyzés-specifikációk között. Egy adott feljegyzéstípus jelzőfeljegyzés-specifikációját az adott feljegyzéstípus szupertípusához adott jelzőfeljegyzés-specifikációk egészítik ki. A jelzőfeljegyzés-specifikációknak nem kell teljesnek lenniük, ahogy ez korábban szükséges volt. A jelzőfeljegyzés-specifikációt az AnnotationPreferences kéri le. Az org.eclipse.ui.texteditor.AnnotationPreferenceLookup segítségével a feljegyzésbeállítás lekérhető egy adott feljegyzéstípushoz, amely a feljegyzésszupertípus-lánccal átlátszó módon végrehajtja a beállítás megadását.

A jelzőfeljegyzés-specifikáció ki lett terjesztve három további attribútummal a függőeleges vonalzón lévő adott feljegyzéstípus egyéni megjelenésének engedélyezése érdekében. Ezek az attribútumok az alábbiak: "icon", "symbolicIcon" és "annotationImageProvider". Az "icon" értéke az ikonképet tartalmazó fájl elérési útja. A "symbolicIcon" értéke az alábbi lehet: "error", "warning", "info", "task", "bookmark". A "symbolicIcon" attribútum előírja a platform számára, hogy a feljegyzést ugyanannak a képnek kell ábrázolnia, mint amelyet a platform használ a hibák, figyelmeztetések, információk, feladatok és könyvjelzők megjelenítéséhez, értelemszerűen. Az "annotationImageProvider" értéke az org.eclipse.ui.texteditor.IAnnotationImageProvider elemet megvalósító osztály, amely teljesen egyéni feljegyzésmegjelenítést tesz lehetővé.

A függőleges vonalzó a társított IAnnotationAccess/IAnnotationAccessExtension elemet használja a feljegyzések lerajzolásához. A függőleges vonalzó nem hívja meg többet az Annotation.paint elemet. A feljegyzések általában nem rajzolják le magukat. A "paint" és "getLayer" metódusok elavulttá váltak a feljegyzés UI-függetlenné tétele érdekében. A DefaultMarkerAnnotationAccess az IAnnotationAccess/IAnnotationAccessExtension alapértelmezett megvalósításaként szolgál. A DefaultMarkerAnnotationAccess az alábbi stratégiát valósítja meg a festésfeljegyzésekhez: Ha a feljegyzés az IAnnotationPresentation elemet valósítja meg, akkor az IAnnotationPresentation.paint kerül meghívásra. Ha nem, akkor feljegyzésbeállításban kieresésre kerül a feljegyzés-képszolgáltató. A feljegyzés-képszolgáltató csak akkor érhető el, ha meg van adva, és a csatoló jelzőfeljegyzés-specifikációt megadó bedolgozó már betöltésre került. Ha itt található egy feljegyzéskép-szolgáltató, akkor a hívás továbbításra kerül hozzá. Ha nem, akkor a megadott "icon" kerül kikeresésre. A rendszer a "symbolicIcon" attribútumot végső visszalépésként használja. Rajzolási feljegyzések esetén a feljegyzésmegjelenítési réteg érdekes. A DefaultMarkerAnnotationAccess az alábbi stratégiával keresi meg a megjelenítési réteget: Ha a feljegyzésbeállítás megad egy beállításréteget, akkor a rendszer a megadott réteget használja. Ha nincs réteg, és a feljegyzés megvalósítja az IAnnotationPresentation elemet, akkor a rendszer az IAnnotationPresentation.getLayer metódust használja, ellenkező esetben a megjelenítési réteg (amely 0) kerül visszaadásra.

Áttérés az annotationTypes kiterjesztési pontra (org.eclipse.ui.editors bedolgozó)

Az org.eclipse.ui.editors bedolgozó az alábbi feljegyzéstípusokat adja meg:

   <extension point="org.eclipse.ui.editors.annotationTypes">
      <type
         name="org.eclipse.ui.workbench.texteditor.error"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="2">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.warning"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="1">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.info"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="0">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.task"
         markerType="org.eclipse.core.resources.taskmarker">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.bookmark"
         markerType="org.eclipse.core.resources.bookmark">
      </type>
   </extension>

A megadott markerAnnotationSpecification kiterjesztés a továbbiakban nem biztosít "markerType" és "markerSeverity" attribútumokat. Ezek a "symbolicIcon" attribútumot adják meg a megfelelő értékkel. A MarkerAnnotation.paint és MarkerAnnotation.getLayer a továbbiakban nem kerül meghívásra, azaz ezen metódusok újradefiniálásának nincs hatása. A befolyásolt ügyfeleknek meg kell valósítaniuk az IAnnotationPresentation elemet.

ILaunchConfigurationType (org.eclipse.debug.core csomag)

A kiterjeszthető indítási módok 3.0 verzióban bevezetésével egy indításikonfiguráció-típushoz több indításdelegálás állhat rendelkezésre. A 3.0 előtti kiadások indítási konfigurációs típusonként csak egy indításdelegálást támogattak. Az ILaunchConfigurationType.getDelegate() metódus már elavult. A getDelegate(String mode) metódust helyben kell használni az indításdelegálás adott indítási módhoz lekéréséhez. Az elavult metódus megváltozott a run mód indításdelegálásának visszaadása érdekében.

ILaunchConfigurationTab és ILaunchConfigurationTabGroup (org.eclipse.debug.ui csomag)

Az indítólap-csoportok és az indítólapok többé nem kapnak értesítést egy indítás befejezéséről. Az ILaunchConfigurationTab és ILaunchConfigurationTabGroup felületen lévő launched(ILaunch) metódus elavult, és nem kerül meghívásra. Erre a metódusra támaszkodó indítási funkció mindig problémás volt, mivel a lapok csak akkor léteznek, ha az indítás az indítás párbeszédablakból kerül végrehajtásra. A háttérindítás bevezetésével ez a metódus már nem hívható meg, mivel az indítás párbeszédablak lezárásra kerül az eredményül kapott indítási objektum létrehozása előtt.

ILaunchConfigurationTab és AbstractLaunchConfigurationTab (org.eclipse.debug.ui csomag)

Két metódus került hozzáadásra az ILaunchConfigurationTab felülethez - az aktivált és letiltott. Ezek az új életciklus-metódusok akkor kerülnek meghívásra, ha a lap be- és kiléptetésre kerül, értelemszerűen. Az ILaunchConfigurationTab meglévő megvalósításai, amelyek alosztályokat hoznak létre a hibakeresés bedolgozó által biztosított absztrakt osztályokhoz (AbstractLaunchConfigurationTab), binárisan kompatibilisek, mivel a metódusok az absztrakt osztályban kerülnek megvalósításra.

A korábbi kiadásokban a lap aktiváláskor az initializeFrom, leállításkor pedig a performApply üzenetet küldte. Ily módon az indítási konfigurációs lap keretrendszer lapok közötti kommunikációt biztosított az indítási konfiguráción keresztül (a konfiguráció aktuális attribútumértékekkel frissítésével, amikor a lap kiléptetésre kerül, valamint az újonnan megadott lap frissítésével). Mivel számos lap nem hajt végre lapok közötti kommunikációt, ez nem mindig használható. Hasonlóan, nem volt lehetőség megkülönböztetni egy éppen aktivált lapot egy olyan laptól, amely első alkalommal jelenített megy egy adott indítási konfigurációt. Az újonnan hozzáadott metódusok segítségével a lapok különbséget tehetnek az aktiválás és inicializálás között, valamint a leállítás és az aktuális értékek mentése között.

Az absztrakt lap által biztosított aktivált elem alapértelmezett megvalósítása meghívja az initializeFrom metódust. A leállított alapértelmezett megvalósítása a performApply metódust hívja meg. Az új API előnyeit kihasználni kívánó lapoknak szükség szerint újra kell definiálniuk ezeket a metódusokat. A lapok közötti kommunikációt nem megvalósító lapok esetén az ajánlott megközelítés a metódusok újbóli megvalósítása, hogy ne csináljanak semmit.

launchConfigurationTabGroup kiterjesztési pont típus (org.eclipse.debug.ui csomag)

A korábbi kiadásokban a perspektívaátkapcsolás az indítási konfiguráción került megadásra az ATTR_TARGET_DEBUG_PERSPECTIVE és ATTR_TARGET_RUN_PERSPECTIVE indítási konfigurációs attribútumokon keresztül. A 3.0 kiterjeszthető indítási módjainak bevezetésével ez a megközelítés már nem méretezhető. A perspektívaátkapcsolás az indítási konfigurációs típus alapján indítási módonként került megadásra, amelyet az indítási konfigurációs típus támogat. Az API hozzáadásra került a DebugUITools elemhez egy adott indítási mód indításikonfiguráció-típusához rendelt perspektíva beállításához és lekéréséhez.

Egy további, elhagyható launchMode elem került hozzáadásra a launchConfigurationTabGroup kiterjesztési ponthoz, ezáltal a közreadott lapcsoport egy alapértelmezett perspektívát adhat meg egy indításikonfiguráció-típushoz és -módhoz.

Az Eclipse felhasználói felületről a felhasználók szerkeszthetik az indításikonfiguráció-típushoz rendelt perspektívát az indítási konfigurációs párbeszédablak megnyitásával, és a fában egy indítási konfigurációs típus csomópont kiválasztásával (egy egyedi konfiguráció helyett). Megjelenik egy lap annak engedélyezése érdekében, hogy a felhasználó minden támogatott indítási módhoz beállítson egy perspektívát.

[JDT only] IVMRunner (org.eclipse.jdt.launching csomag)

Két metódus került hozzáadásra a VMRunnerConfiguration osztályhoz a környezeti változók beállításának és lekérésének támogatása érdekében. Az IVMRunner megvalósítóinak meg kell hívniuk a VMRunnerConfiguration.getEnvironment() metódust, és át kell adniuk ezt a környezetet a végrehajtott JVM-nek. A DebugPlugin.exec(String[] cmdLine, File workingDirectory) metódust használó ügyfelek ezt a DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp) meghívásával hajthatják végre. A getEnvironment() eredmény egyszerű átadása elegendő.

[Csak JDT] VMRunnerConfiguration és Bootstrap osztályok (org.eclipse.jdt.launching csomag)

A korábbi kiadásokban a rendszerbetöltési elérési út leírásához a VMRunnerConfiguration rendelkezett egy attribútummal. Az attribútum az -Xbootclasspath argumentumban megadásra kerülő Stringek gyűjteménye. A JVM-ek támogatása érdekében három új attribútum került hozzáadásra a VMRunnerConfiguration elemhez, amelyek lehetővé teszik a rendszerbetöltési elérési út hozzáfűzését, és az elérési úthoz fűzést. A hozzáadott új metódusok/attribútumok az alábbiak:

A régi getBootClassPath() attribútum továbbra is létezik, és a három új attribútumnak megfelelő teljes elérési utat tartalmaz. Az új rendszerbetöltési elérési utat támogató VMRunners elemnek ki kell használnia az új attribútumok előnyeit.

[Csak JDT] Javított támogatás a működő példányokhoz (org.eclipse.jdt.core csomag)

A Java modell működő példány szolgáltatása a jelentősen javított funkcionalitás biztosítása érdekében 3.0 verzióban átdolgozásra került. A 3.0 verzió előtt a Java modell lehetővé tette a fordítási egység egyéni működő példányainak létrehozását. A működő példány módosítható, és később véglegesíthető. Támogatva volt a Java-modell maradékának kontextusában a működő példány korlátozott elemzése. Ugyanakkor ezek az elemzések semmilyen módon nem tudtak egynél több működő példányt figyelembe venni.

A 3.0 módosításai lehetővé teszik fordítási egységek működő példányainak létrehozását és kezelését, és elemzéseket hajthatnak végre az összes működő példány jelenlétében. Például most már egy, a JDT-újraíráshoz hasonló ügyfél számára, hogy működő példányokat hozzon létre egy vagy több módosítani kívánt fordítási egységhez, majd ezek után feloldja a működő példányok típushivatkozásait. Korábban ez csak a fordítási egység működő példányok módosításainak elfogadása után volt lehetséges.

A Java modell API kétféleképpen változik a jobb támogatás biztosítása érdekében:

(1) A korábban az IWorkingCopy elemen megtalálható, és az ICompilationUnit által örökölt funkciók az ICompilationUnit elembe lettek egyesítve. Az IWorkingCopy felület csak ezen a helyen volt használható, és indokolatlanuk általánosabb volt, mint aminek kellett lennie. Ez a módosítás leegyszerűsíti az alkalmazás programozási felületet. Az IWorkingCopy elavult. Az alkalmazás programozási felület más helyei, ahol az IWorkingCopy paraméterként vagy eredménytípusként került használatra, szintén elavultak; a helyettesítő API metódusok az ICompilationUnit elemet használják az IWorkingCopy helyett.

(2) Az IBufferFactory felületet a WorkingCopyOwner helyettesíti. A működő példányok jobb támogatásához az szükséges, hogy egy objektum birtokolja a működő példányokat. Annak ellenére, hogy az IBufferFactory a megfelelő helyen van, a név nem adja meg megfelelően, hogy az új működő példány mechanizmus hogyan működik. A WorkingCopyOwner sokatmondóbb. A WorkingCopyOwner felület helyett absztrakt osztályként került megadásra annak lehetővé tétele érdekében, hogy a működő példány tulajdonos elképzelése kiértékelésre kerüljön a jövőben. The one method on IBufferFactory moves to WorkingCopyOwner unaffected. A WorkingCopyOwner nem valósítja meg az IBufferFactory elemet annak egyértelművé tétele érdekében, hogy az IBufferFactory a múlt eleme. Az IBufferFactory elavult. Az API más helyei, ahol az IBufferFactory paraméterként vagy eredménytípusként jelenik meg, szintén elavultak; a helyettesítő API metódusok a WorkingCopyOwner elemet használják az IBufferFactory helyett.

Ezen módosítok nem törik meg a bináris kompatibilitást.

Átállításkor az IWorkingCopy típusra mutató összes hivatkozásnak a ICompilationUnit elemre kell hivatkoznia. Az IWorkingCopy megvalósítása megvalósítja az ICompilationUnit típust is, vagyis az IWorkingCopy típusú objektumok nyugodtan adhatók meg ICompilationUnit típusúként.

Az IBufferFactory elemet megvalósító osztálynak helyettesítenie kell a WorkingCopyOwner alosztályát. Annak ellenére, hogy a WorkingCopyOwner nem valósítja meg az IBufferFactory elemet, meg lehet határozni a WorkingCopyOwner alosztályait, amely megvalósítja az IBufferFactory elemet, és ezáltal létrehoz egy hidat a régi és új elem között (az IBufferFactory deklarálja a createBuffer(IOpenable) elemet, a WorkingCopyOwner pedig a createBuffer(ICompilationUnit) elemet; az ICompilationUnit kiterjeszti az IOpenable elemet).

Mivel az IWorkingCopy és IBufferFactory módosításai összefüggenek, ajánlatos mindkettőt egyszerre kezelni. Az elavulások részletei a következők:

Az org.eclipse.help bedolgozó átstrukturálása

Az org.eclipse.help bedolgozó, amely az alkalmazás programozási felületeket és kiterjesztési pontokat tárolja a súgórendszer kiegészítéséhez és kiterjesztéséhez, és megjeleníti a súgót, csak alkalmazás programozási felületeket és kiterjesztési pontokat biztosítanak a súgóerőforrások kiegészítéséhez és eléréséhez. A bedolgozóban tárolt alapértelmezett súgó UI megvalósítás egy része az alkalmazás programozási felületekkel együtt átkerült egy új org.eclipse.help.base bedolgozóba a megvalósítás kiterjesztése érdekében. A Súgó UI kiegészítésére és a súgó megjelenítésére szolgáló alkalmazás programozási felületek és kiterjesztési pont átkerült az org.eclipse.ui bedolgozóba. Ez az átstrukturálás nagyobb rugalmasságot biztosít az alkalmazások számára a súgórendszert illetőleg; az új struktúra segítségével az alkalmazások az általános munkaterület alapján saját Súgó UI és/vagy Súgó megvalósítást biztosíthatnak, vagy teljes egészében kihagyhatják a súgórendszert.

Mivel az érintett kiterjesztési pontokat és API csomagokat csak maga a súgórendszer használja, nem valószínű, hogy ez a módosítás hatással van a meglévő bedolgozókra. Ezeket a teljesség kedvéért adjuk meg:

Új keresés UI API

Egyéni kereséseket megvalósító új API került hozzáadásra a 3.0 verzióhoz. Az eredeti API elavult a 3.0 verzióban, és az ügyfeleket érdemes átírni az org.eclipse.search.ui és org.eclipse.search.ui.text csomagban lévő új alkalmazás programozási felületre.

Az ügyfeleknek létre kell hozniuk az ISearchQuery, ISearchResult és ISearchResultPage megvalósítását. Az ISearchResultPage megvalósítást ezután hozzá kell adni az új org.eclipse.search.searchResultViewPages kiterjesztési ponthoz.

Az ISearchResult és ISearchResultPage alapértelmezett megvalósításai az org.eclipse.search.ui.text csomagban kerülnek megadásra.

üres üzenetek a MessageBox és DirectoryDialog elemben (org.eclipse.swt.widgets csomag)

A 3.0 verzió előtt ha az SWT DirectoryDialog.setMessage(String string) vagy MessageBox.setMessage(String string) metódus nulla karaktersorozat-értékkel kerül meghívásra, akkor a párbeszédablak címében nem jelenik meg szöveg. Ez a viselkedés meghatározatlan (nulla átadása sosem engedélyezett) és problémát okoz a getMessage függvény esetén, amely nem adhat vissza nullát. A 3.0 kiadásban a nullérték átadása egy IllegalArgumentException kivételt eredményez. A specifikációk megváltoztak és jelölik ezt, egységessé téve a Dialog.setMessage szülőosztállyal. Ha a Dialog.setMessage osztályt használja, akkor győződjön meg róla, hogy az átadott karaktersorozat sosem nulla. Egyszerűen egy üres karaktersorozatot adjon át, ha a párbeszédablakot szöveg nélkül kívánja megjeleníteni.

Modális folyamat-visszajelzés javítása

A párhuzamos műveletek támogatás kifinomultabb módszert igényel a modális folyamat megjelenítéséhez. A válaszkészég részeként a további folyamattámogatás az IProgressService osztályban került megvalósításra. A meglévő módszer a folyamat ProgressMonitorDialog elemmel megjelenítése továbbra is működik. A felhasználói élmény javítása érdekében javasoljuk az új IProgressService elemre áttérést.

A Modális folyamat megjelenítése az Eclipse 3.0 verzióban dokumentum leírja, hogy hogyan kell áttérni az új IProgressService szolgáltatásra.

A Hibakeresés tevékenységcsoportok eltávolításra kerültek

A Hibakeresés tevékenységcsoportok kiterjesztési pont (org.eclipse.debug.ui.debugActionGroups) eltávolításra került. Az Eclipse 3.0 verzióban a munkaterület az org.eclipse.platform.ui.activities kiterjesztési ponton keresztül támogatást vezetett be a Tevékenységekhez. Ez a támogatás biztosít mindent, amelyet a Hibakeresés tevékenységcsoportok biztosítottak és a használata egyszerűbb (támogatja a mintákat az összes tevékenység megadása helyett), és rendelkezik egy programozható alkalmazás programozási felülettel ennek támogatásához. A régi kiterjesztési pontra mutató hivatkozások eltávolításának meghiúsulása nem okoz hibát. A kiterjesztési pont hivatkozásai egyszerűen figyelmen kívül maradnak. A termékgyártók számára javasoljuk, hogy használják a munkaterület Tevékenységek funkciójának támogatását a nyelvspecifikus hibakeresési műveletek nyelvspecifikus tevékenységekkel társítása érdekében (például a C++ hibakeresési műveletek társíthatók egy "C++ fejlesztés" nevű tevékenységgel).

A BreakpointManager letiltható

Az IBreakpointManager a setEnabled(boolean) és isEnabled() metódust adja meg. Ha a töréspontkezelő le van tiltva, akkor a hibakeresőknek az összes bejegyzett töréspontot figyelmen kívül kell hagyniuk. A hibakeresés platform egy új figyelőmechanizmust - IBreakpointManagerListener - is biztosít, amelynek segítségével az ügyfelek regisztrálhatók a töréspontkezelőhöz, hogy értesítést kapjanak az engedélyezettség változásáról. A Töréspontok nézet meghívja ezt az alkalmazás programozási felületet egy új átkapcsolás tevékenységből, amelynek segítségével a felhasználó "Átugorhatja az összes töréspontot." A töréspontkezelő engedélyezettségét nem elfogadó hibakeresők egyes dolgokat megszakítva jelenítenek meg, ha a felhasználó ezt a szolgáltatást próbálja használni.

[Csak JDT] Java keresés-résztvevők (org.eclipse.jdt.core.search csomag)

A Java-közeli nyelveknek (mint például a JSP, SQLJ, JWS, stb.) részt kell tudniuk venni a Java keresésben. Az ilyen nyelvek megvalósítóinak az alábbiakat kell tudniuk:

Az ilyen megvalósítót keresés-résztvevőnek hívják. Ez kiterjeszti a SearchParticipant osztályt. A keresés-résztvevők átkerülnek a keresési lekérdezésekbe (lásd: SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).

Az egyezések indexelésekor vagy keresésekor a keresés-résztvevőnek meg kell adnia a SearchDocument egy alosztályát, amely a getByteContents() vagy getCharContents() újradefiniálásával lekérheti a dokumentum tartalmát. A getDocument(String) ezen alosztály egy példányát adja vissza.

A keresés-résztvevő, amely indexelni kíván néhány dokumentumot, a SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) metódust fogja használni az adott dokumentum adott indexelés szerinti indexelésének ütemezéséhez. Ha a dokumentum készen áll az indexelésre, akkor az alapul szolgáló keretrendszer meghívja a SearchParticipant.indexDocument(SearchDocument, IPath) metódust. A keresés-résztvevő ezután veszi a dokumentum tartalmát, elemzi és a SearchDocument.addIndexEntry(char[], char[]) segítségével indexbejegyzéseket ad hozzá.

Ha az indexelés kész, akkor az indexek a SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) segítségével lekérhetők és az egyezések megkereshetők. Ez először a SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope) segítségével minden résztvevőtől lekéri a lekérdezéshez szükséges indexeket. Az adott mintának megfelelő indexbejegyzésekhez a keresés résztvevő lekérdezésével létrehozásra kerül egy keresési dokumentum (lásd getDocument(String)). Ezek a dokumentumok átkerülnek a keresés-résztvevőhöz, így a locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor) segítségével megkeresheti az egyezéseket. A keresés-résztvevő az acceptSearchMatch(SearchMatch) segítségével értesíti a SearchRequestor elemet a keresési egyezésekről, és átadja a SearchMatch alosztály egyik példányát.

A keresés-résztvevő delegálhatja a munka egy részét az alapértelmezett Java keresés-résztvevőhöz. Ezen alapértelmezett résztvevő példánya a SearchEngine.getDefaultSearchParticipant() segítségével kerül lekérésre. Az egyezéskeresési kéréskor például az SQLJ résztvevő a .sqlj dokumentumokból létrehozhat .java dokumentumokat, és a .java dokumentumok segítségével delegálhatja a munkát az alapértelmezett résztvevőnek.