Změny potřebné při adoptování mechanizmů a rozhraní API verze 3.0

Tento oddíl popisuje změny, které jsou nutné, pokud se pokoušíte změnit svůj modul plug-in pro verzi 2.1 tak, aby adoptoval mechanizmy a rozhraní API verze 3.0.

Opuštění org.eclipse.core.runtime.compatibility

Běhová komponenta platformy Eclipse verze 3.0 se výrazně liší. Základní implementace je založena na základě specifikace rámce OSGi. Běhová komponenta Eclipse 3.0 obsahuje vrstvu kompatibility (v modulu plug-in org.eclipse.core.runtime.compatibility), která udržuje rozhraní API verze 2.1. Vývojáři modulů plug-in, kteří se zajímají o přidaný výkon a funkce, by měli zvážit použití rozhraní API verze 3.0 a odebrání závislosti na úrovni vrstvy kompatibility. Kód pro kompatibilitu se vyskytuje na třech místech:

V níže uvedeném textu najdete další podrobnosti o tom, které třídy a metody jsou přítomny z důvodu kompatibility, a také návod, jak svůj modul plug-in aktualizovat.

Moduly plug-in a balíky

Běhová komponenta Eclipse byla rozdělena do dvou částí: načítání tříd se správou nezbytných předpokladů a správu rozšíření/bodů rozšíření. Toto rozdělení umožňuje přirozené a hladké zavedení specifikace struktury OSGi pro načítání tříd a správu nezbytných předpokladů. To zase zpřístupňuje řadu nových schopností v běhové komponentě, od dynamické instalace/aktualizace/odinstalování modulů plug-in po zabezpečení a lepší konfigurovatelnost.

I když budeme nadále mluvit o modulech plug-in, v nové běhové komponentě je modul plug-in ve skutečnosti balíkem spolu s nějakými rozšířeními a body rozšíření. Termín balík je definován ve specifikaci struktury OSGi a označuje kolekci typů a prostředků spolu s přidruženými informacemi o mezibalíkových předpokladech. Registr rozšíření je nová forma registru modulů plug-in a obsahuje pouze podrobné informace o rozšířeních a bodech rozšíření. Celkově je rozhraní API registru rozšíření shodné s odpovídajícím rozhraním API registru modulů plug-in (viz Registry, kde najdete další informace).

V běhové komponentě Eclipse 2.x má objekt modulu plug-in množství rolí a zodpovědností:

V obrázku běhové komponenty Eclipse 3.0 jsou tyto role a zodpovědnosti rozloženy do samostatných objektů.

Balík
Balík je jednotkou modularity OSGi. V balíku existuje jeden zaváděč tříd a lze zkonstruovat grafy závislostí zavádění tříd mezi balíky podobně jako v Eclipse. Balíky mají životní cyklus pro spuštění a zastavení a rámec OSGi rozesílá události, které se k balíkům vztahují (např. instalace, vyřešení, spuštění, zastavení, odinstalování, ...), stranám, které se o ně zajímají. Oproti třídě Plugin platformy Eclipse se třída Bundle struktury OSGi nedá rozšiřovat. To znamená, že vývojáři nemají možnost definovat svou vlastní třídu balíku.
BundleActivator
BundleActivator je rozhraní definované rámcem OSGi. Každý balík může definovat třídu aktivátoru balíku, podobně jako modul plug-in může definovat svou třídu Plugin. Rámec vytvoří instanci uvedené třídy a použije ji k implementaci zpracování životního cyklu metodami start() a stop(). Existuje nicméně podstatný rozdíl v charakteru tohoto zpracování životního cyklu. V Eclipse je běžné (ačkoliv nedoporučeno), aby třídy Plugin prováděly jak inicializaci, tak registraci. V OSGi musí aktivátory provádět pouze registraci. Provádění velkého množství inicializací (nebo jakékoliv jiné práce) v metodě BundleActivator.start() ohrožuje živost systému.
BundleContext
Kontexty BundleContext jsou mechanizmem OSGi k odkrývání obecných funkcí systému pro jednotlivé balíky. Každý balík má jedinečnou a soukromou instanci BundleContext, kterou může použít pro přístup k systémovým funkcím (např. funkci getBundles(), která objeví všechny balíky v systému).
Plugin
Nová třída Plugin se velmi podobá původní třídě Plugin platformy Eclipse s následujícími výjimkami: Objekty Plugin nejsou nadále požadovány ani spravovány běhovou komponentou a různé metody jsou nyní nepřípustné. Je to v podstatě komfortní mechanizmus, který poskytuje spoustu užitečných funkcí a mechanizmů, ale není nadále nezbytně nutný. Většina funkcí, které jsou zde poskytnuty, je rovněž k dispozici ve třídě Platform v běhové komponentě.

Třída Plugin také implementuje BundleActivator. To proto, že je pohodlné, když jeden centrální objekt reprezentuje životní cyklus a sémantiku modulu plug-in. Všimněte si nicméně, že se tím neschvaluje horlivá inicializace datových struktur, která je dnes v modulech plug-in běžná. Musíme stále zdůrazňovat, že moduly plug-in se mohou aktivovat i tím, že se během verifikace třídy v nějakém jiném modulu plug-in odkazovalo na poněkud periferní třídu. Tedy pouhá aktivace vašeho modulu plug-in ještě neznamená, že jsou jeho funkce potřebné. Rovněž vezměte na vědomí, že vám nic nebrání definovat si vlastní třídu BundleActivator nebo žádný aktivátor balíku nepoužít.

Kroky nezbytné k portování třídy Plugin pro verzi 2.x do Eclipse 3.0 záleží na tom, co třída dělá. Jak bylo nastíněno výše, většina práce na začátku životního cyklu spadá do jedné z následujících kategorií:

Inicializace
Inicializace datové struktury a modelu se poměrně často provádí v metodě Plugin.startup(). Přirozené/zřejmé mapování by bylo provádět tuto práci v metodě BundleActivator.start(), to jest, nechat tuto funkci na třídě Plugin. To je velmi nevhodné. Podobně jako u modulů plug-in pro verzi 2.x, balíky/moduly plug-in pro verzi 3.0 se mohou spouštět z mnoha různých důvodů a za mnoha různých okolností.
Skutečný příklad z doby Eclipse 2.0 tento případ osvětlí. Existoval modul plug-in, který inicializoval velký model vyžadující načtení nějakých 11 MB kódu a mnoha megabajtů dat. Byly celkem běžné případy použití, kdy se tento modul plug-in aktivoval, aby se zjistilo, zda se má ikona projektu prezentovaná v navigátoru ozdobit určitým markupem. Tento test nevyžadoval žádnou inicializaci prováděnou v metodě startup(), ale přesto ve všech případech použití museli všichni uživatelé platit za tuto horlivou inicializaci daň v podobě času a paměti.
Alternativním přístupem je provádět podobné inicializace klasickým pomalým stylem. Například inicializaci modelů neprovádějte při aktivaci modulu plug-in/balíku, ale tehdy, až budou skutečně potřebné (např. v metodě centralizovaného objektu pro přístup k modelu). V mnoha případech použití to nastane v téměř shodném bodě v čase, ale v jiných scénářích tento přístup inicializaci odloží (možná navždy). Při portování modulů z verze 2.1 doporučujeme najít si čas ke zvážení použité inicializační strategie.
Registrace
Spuštění modulu plug-in je vhodnou dobou pro registraci listenerů, služeb atd. a pro spuštění vláken pro zpracování na pozadí (např. naslouchání na soketu). Plugin.start() může být přiměřeným místem k provedení této práce. Rovněž může mít smysl ji odložit až do výskytu nějakého jiného spouštěcího impulsu (např. použití konkrétní funkce nebo datového prvku).
Globální data modulu plug-in
Vaše třída Plugin může nadále hrát tuto roli. Hlavní záležitostí je, že objekty Plugin nejsou nadále globálně přístupné prostřednictvím seznamu spravovaného systémem. V Eclipse 2.x bylo možno objevit objekt Plugin libovolného modulu plug-in prostřednictvím registru modulů plug-in. To nadále není možné. Za většiny okolností není tento typ přístupu nezbytný. Objekty Plugin, ke kterým se přistupuje prostřednictvím registru, se typičtěji používají jako obecné objekty Plugin, než jako volání metod specifických pro doménu. Ekvivalentní úrovně schopností lze dosáhnout přístupem k odpovídajícím objektům Bundle a manipulací s nimi.

Registry a model modulu plug-in

V nové běhové komponentě se oddělují informace a struktury potřebné ke spuštění modulu plug-in od těch, které se vztahují k rozšířením a bodům rozšíření modulu plug-in. První z nich definuje a spravuje specifikace rámce OSGi. Druhé z nich jsou koncepty specifickými pro Eclipse a přidává je kód běhové komponenty platformy Eclipse. Podobně se původní registr modulů plug-in a související objekty rozdělily do balíků struktury OSGi a registru rozšíření platformy Eclipse.

Části rozhraní IPluginRegistry, které se zabývají specifikací provedení (např. IPluginDescriptor, ILibrary, IPrequisite), jsou nyní nepřípustné a zbývající části související s rozšířeními a body rozšíření byly přesunuty do IExtensionRegistry. Dále, takzvané modelové objekty, které se týkají registru modulů plug-in jako celku, jsou nyní nepřípustné. Běhová komponenta nabízela tyto typy a vytvářela jejich instance zejména pro podporu nástrojů, jako např. prostředí PDE. Bohužel bylo častým případem, že úroveň potřebných informací překračovala schopnosti nebo zájmy běhové komponenty (např. pamatování si čísel řádků pro prvky souboru plugin.xml), takže nakonec si potenciální spotřebitelé informací běhové komponenty museli stejně udržovat své vlastní struktury.

V nové běhové komponentě jsme přehodnotili systémové prostředky poskytované běhovou komponentou a nyní poskytujeme pouze takové, které jsou buď nezbytné pro provádění běhové komponenty, nebo je jiní mohou provádět velmi obtížně. Jak bylo zmíněno výše, modelové objekty registru modulů plug-in i rozhraní API pro analýzu modulů plug-in jsou nyní nepřípustné. Nový registr rozšíření udržuje nezbytné informace související s rozšířeními. Nová struktura state (viz org.eclipse.osgi.service.resolver.State a spřátelené funkce) reprezentuje nezbytné informace související s prováděním a umožňuje s nimi manipulovat.

Struktura fragmentů NL

Struktura fragmentů NL byla v Eclipse 3.0 aktualizována, aby byla konzistentnější. Dříve se předpokládalo, že překlady souborů, jako např. plugin.properties, budou uvnitř souborů JAR dodaných fragmenty. Jelikož se původní soubory nalézají v kořenovém adresáři příslušného hostitelského modulu plug-in, konzistentnější by bylo umístit přeložené soubory do kořene fragmentů NL. Například

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

Zde si všimněte, že soubor nl1.jar by dříve obsahoval překlady pro plugin.properties. Tyto soubory jsou nyní v kořenovém adresáři fragmentu a soubor JAR obsahuje překlady veškerých přeložitelných prostředků (tj. souborů načítaných pomocí zaváděče tříd) v hostitelském modulu plug-in.

Struktura fragmentů NL z Eclipse 2.1 NL je samozřejmě stále podporována pro hostitelské moduly plug-in z verze 2.1, které běží v Eclipse 3.0. Nemůžete však použít fragment NL z verze 2.1 v modulu plug-in pro verzi 3.0. Fragment je třeba aktualizovat na novou strukturu.

Přehled změn rozhraní API

org.eclipse.core.boot (balíček org.eclipse.core.boot)

Celý balíček org.eclipse.core.boot je nyní nepřípustný. Třída BootLoader byla sloučena s org.eclipse.core.runtime.Platform, protože nadále nemá smysl rozdělovat zavádění a dobu běhu programu. Všimněte si, že modul plug-in org.eclipse.core.boot byl v podstatě rozebrán a veškerý jeho kód se přesunul buď do nové běhové komponenty, nebo do vrstvy kompatibility.

Rozhraní IPlatformConfiguration bylo vždy typem definovaným komponentou instalace/aktualizace platformy Eclipse a pro tuto komponentu. S reorganizací běhové komponenty můžeme tento typ vrátit do jeho právoplatného domovského umístění. Tato třída zůstává z větší části nezměněna a byla znovu sbalena jako org.eclipse.update.configurator.IPlatformConfiguration.

Rozhraní IPlatformRunnable bylo přesunuto do org.eclipse.core.runtime.IPlatformRunnable.

IExtension a IExtensionPoint (balíček org.eclipse.core.runtime)

Metoda getDeclaringPlugin() (v obou třídách) poskytuje propojení na nadřazený modul plug-in, který deklaruje příslušné rozšíření nebo bod rozšíření. Novy model registru odděluje aspekty provádění modulů plug-in od aspektů rozšíření/bodů rozšíření a nadále neobsahuje rozhraní IPluginDescriptor. Uživatelé tohoto rozhraní API by měli zvážit novou metodu getParentIdentifier(), která se nalézá v rozhraní IExtension i IExtensionPoint.

ILibrary, IPluginDescriptor, IPluginRegistry a IPrerequisite (balíček org.eclipse.core.runtime)

V původní běhové komponentě udržoval registr modulů plug-in kompletní obrázek o konfiguraci běhové komponenty. V Eclipse 3.0 je tento obrázek rozdělen mezi strukturu OSGi a registr rozšíření. Tyto třídy jako takové byly označeny za nepřípustné. Upozornění na nepřípustnost obsahují podrobnosti o způsobu, jak byste měli svůj kód aktualizovat.

Platform a Plugin (balíček org.eclipse.core.runtime)

V nové běhové komponentě nejsou objekty Plugin nadále spravovány běhovou komponentou a tedy k nim nelze obecně přistupovat prostřednictvím třídy Platform. Podobně registr modulů plug-in nadále neexistuje a neposkytuje přístup k deskriptorům modulů plug-in. Nicméně dostupné jsou vhodné náhradní metody, které jsou podrobně popsány v dokumentaci Javadoc k nepřípustným metodám v těchto třídách.

org.eclipse.core.runtime.model (balíček org.eclipse.core.runtime.model)

Všechny typy v tomto balíčku jsou nyní nepřípustné. Viz diskuse o registrech, kde jsou další informace.

IWorkspaceRunnable a IWorkspace.run (balíček org.eclipse.core.resources)

Klienti metody IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) by měli přezkoumat, jak tuto metodu používají, a zvážit použití bohatší metody IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). Stará metoda IWorkspace.run získává zámek celého pracovního prostoru po dobu trvání IWorkspaceRunnable. To znamená, že operace prováděná pomocí této metody nikdy nebude schopna běžet souběžně s jinými operacemi, které upravují pracovní prostor. V Eclipse 3.0 bylo mnoho dlouhodobých operací přesunuto do vláken na pozadí, takže pravděpodobnost konfliktů mezi operacemi se výrazně zvýšila. Pokud je modální operace na popředí zablokována dlouhodobou operací na pozadí, uživatelské rozhraní se zablokuje, dokud se operace na pozadí nedokončí, nebo dokud se jedna z operací nezruší.

Navrženým řešením je přepnout všechny odkazy na starou metodu IWorkspace.run tak, aby používaly novou metodu s parametrem pravidla plánování. Pravidlo plánování by mělo být co nejjemnějším pravidlem, které zahrnuje pravidla pro všechny změny provedené touto operací. Pokud se operace pokusí upravovat prostředky mimo rozsah pravidla plánování, vyskytne se běhová výjimka. Přesné pravidlo plánování, které požaduje daná operace pracovní plochy, není uvedeno a může se měnit v závislosti na instalovaném poskytovateli úložiště v daném projektu. K získání pravidla plánování pro operaci, která mění prostředky, by se měla použít továrna IResourceRuleFactory. V případě potřeby lze použít MultiRule k určení více pravidel prostředků a pohodlnou metodu MultiRule.combine lze použít ke sloučení pravidel z různých operací, které mění prostředky.

Není-li zamykání nezbytné, lze použít pravidlo plánování null. To umožní objektu procesu runnable upravovat všechny prostředky v pracovním prostoru, ale nezabrání jiným vláknům pracovní prostor souběžně také upravovat. Pro jednoduché změny pracovního prostoru je to často nejjednodušší a z hlediska souběžnosti nejvhodnější řešení.

IWorkbenchPage (balíček org.eclipse.ui)

IEditorDescriptor (balíček org.eclipse.ui)

ISharedImages (balíček org.eclipse.ui)

IWorkbenchActionConstants (balíček org.eclipse.ui)

IWorkbenchPreferenceConstants (balíček org.eclipse.ui)

IExportWizard (balíček org.eclipse.ui)

IImportWizard (balíček org.eclipse.ui)

INewWizard (balíček org.eclipse.ui)

WorkbenchHelp (balíček org.eclipse.ui.help)

IHelp (balíček org.eclipse.help)

ITextEditorActionConstants (balíček org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds (balíček org.eclipse.ui.texteditor)

BasicTextEditorActionContributor (balíček org.eclipse.ui.texteditor)

TextEditorActionContributor (balíček org.eclipse.ui.editors.text)

Bod rozšíření annotationTypes (modul plug-in org.eclipse.ui.editors)

Nyní existuje explicitní pojem typu anotace. Viz Annotation.getType() a Annotation.setType(). Typ anotace se může po dobu jejího trvání změnit. Byl přidán nový bod rozšíření pro deklaraci typů anotací: "org.eclipse.ui.editors.annotationTypes". Typ anotace má název a může se deklarovat jako podtyp jiného deklarovaného typu anotace. Deklarace typu anotace může rovněž používat atributy "markerType" a "markerSeverity" k určení, že značkovače daného typu a dané závažnosti mají být v textových editorech reprezentovány jako anotace konkrétního typu. Atributy "markerType" a "markerSeverity" v "org.eclipse.ui.editors.markerAnnotationSpecification" by se neměly nadále používat. Specifikace anotací značkovačů se tedy stávají nezávislé na značkovačích a název je tedy zavádějící. Nicméně se název zachovává k zajištění zpětné kompatibility.

Instance podtříd třídy AbstractMarkerAnnotationModel automaticky detekují a nastavují správné typy anotací pro anotace, které vytvářejí ze značkovačů. Chcete-li v programu načíst typ anotace pro daný značkovač nebo daný pár atributů markerType a markerSeverity, použijte org.eclipse.ui.texteditor.AnnotationTypeLookup.

Přístup k hierarchii typů anotací poskytuje IAnnotationAccessExtension. Pro daný typ anotace můžete získat řetěz supertypů a zkontrolovat, zda je typ anotace podtypem jiného typu anotace. Třída DefaultMarkerAnnotationAccess implementuje toto rozhraní.

Bod rozšíření markerAnnotationSpecification (modul plug-in org.eclipse.ui.editors)

Typ anotace je klíčem, pomocí kterého se hledá přidružená specifikace anotace značkovače. Jelikož typy anotací mohou rozšiřovat jiné typy anotací, existuje také implicitní relace mezi specifikacemi anotací značkovačů. Proto je specifikace anotace značkovače pro daný typ anotace dokončena specifikacemi anotací značkovačů poskytnutých pro supertypy daného typu anotace. Specifikace anotací značkovačů tedy nemusí být úplné, což bylo dříve nezbytné. Specifikace anotací značkovačů se načítají s použitím AnnotationPreferences. Použijete-li org.eclipse.ui.texteditor.AnnotationPreferenceLookup, můžete načíst předvolbu anotace pro daný typ anotace, která transparentně provede dokončení předvolby podél řetězce supertypů anotací.

Specifikace anotace značkovače byla rozšířena o tři další atributy, aby umožňovala definovat vlastní vzhledy daného typu anotace ve vertikálním pravítku. Tyto atributy jsou: "icon", "symbolicIcon" a "annotationImageProvider". Hodnotou atributu "icon" je cesta k souboru, který obsahuje obrázek ikony. Atribut "symbolicIcon" může mít jednu z hodnot "error", "warning", "info", "task", "bookmark". Atribut "symbolicIcon" platformě říká, že se anotace má zobrazit se stejným obrázkem, jaký platforma používá pro prezentaci chyb, varování, informací, úloh a záložek. Hodnotou atributu "annotationImageProvider" je třída, která implementuje org.eclipse.ui.texteditor.IAnnotationImageProvider a umožňuje plně přizpůsobit prezentaci anotací.

Vertikální pravítko používá pro kreslení anotací svá přidružená rozhraní IAnnotationAccess/IAnnotationAccessExtension. Vertikální pravítko nadále nevolá metodu Annotation.paint. Obecně se anotace (Annotation) již nemají samy vykreslovat. Metody "paint" a "getLayer" jsou nyní nepřípustné, aby se anotace nakonec staly nezávislými na uživatelském rozhraní. DefaultMarkerAnnotationAccess slouží jako výchozí implementace rozhraní IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementuje pro vykreslování anotací následující strategii: Pokud anotace implementuje rozhraní IAnnotationPresentation, zavolá se IAnnotationPresentation.paint. Pokud ne, vyhledá se v předvolbě anotace poskytovatel obrázku anotace. Poskytovatel obrázku anotace je k dispozici pouze tehdy, pokud je specifikován a pokud byl již zaveden modul plug-in, který definuje zapouzdřující specifikaci anotace značkovače. Existuje-li poskytovatel obrázku anotace, volání se mu postoupí. Pokud ne, vyhledá se zadaná ikona ("icon"). Jako poslední možnost se použije atribut "symbolicIcon". Pro kreslení anotací je důležitá prezentační vrstva anotací. DefaultMarkerAnnotationAccess vyhledá prezentační vrstvu pomocí následující strategie: Pokud předvolba anotace uvádí prezentační vrstvu, použije se zadaná vrstva. Pokud žádná vrstva neexistuje a anotace implementuje rozhraní IAnnotationPresentation, použije se IAnnotationPresentation.getLayer, jinak se vrátí výchozí prezentační vrstva (což je 0).

Migrace na bod rozšíření annotationTypes (modul plug-in org.eclipse.ui.editors)

Modul plug-in org.eclipse.ui.editors deklaruje následující typy anotací:

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

Definovaná rozšíření markerAnnotationSpecification nadále neposkytují atributy "markerType" a "markerSeverity". Definují atribut "symbolicIcon" s příslušnou hodnotou. Takže metody MarkerAnnotation.paint a MarkerAnnotation.getLayer se již nadále nevolají, tj. jejich předefinování nemá žádný efekt. Ovlivnění klienti by měli implementovat rozhraní IAnnotationPresentation.

ILaunchConfigurationType (balíček org.eclipse.debug.core)

Od zavedení rozšiřitelných režimů spuštění ve verzi 3.0 může pro daný typ konfigurace spuštění existovat více delegátů spuštění. Verze starší než 3.0 podporovaly pouze jednoho delegáta spuštění na typ konfigurace spuštění. Metoda ILaunchConfigurationType.getDelegate() je nyní nepřípustná. Místo ní by se pro získání delegáta spuštění pro konkrétní režim spuštění měla používat metoda getDelegate(String mode). Nepřípustná metoda byla změněna tak, že vrací delegáta spuštění pro režim run.

ILaunchConfigurationTab a ILaunchConfigurationTabGroup (balíček org.eclipse.debug.ui)

Skupiny karet spuštění a karty spuštění se nadále neupozorňují, když se spuštění dokončí. Metoda launched(ILaunch) v rozhraních ILaunchConfigurationTab a ILaunchConfigurationTabGroup je nyní nepřípustná a nadále se nevolá. Spoléhání se na tuto metodu ve funkcích spuštění bylo vždy problematické, protože karty existují pouze tehdy, když se spouštění provádí z dialogového okna spuštění. Rovněž po zavedení spouštění na pozadí nelze tuto metodu nadále volat, protože dialogové okno spuštění se zavře ještě předtím, než výsledný objekt spuštění začne existovat.

ILaunchConfigurationTab a AbstractLaunchConfigurationTab (balíček org.eclipse.debug.ui)

Do rozhraní ILaunchConfigurationTab byly přidány dvě metody - activated a deactivated. Tyto nové metody životního cyklu se volají při vstupu do karty a při jejím opuštění. Stávající implementace rozhraní ILaunchConfigurationTab, jenž vytvářejí podtřídu abstraktní třídy, kterou poskytuje modul plug-in ladění (AbstractLaunchConfigurationTab), jsou binárně kompatibilní, protože metody jsou v abstraktní třídě implementovány.

V předchozích verzích se kartě zasílala zpráva initializeFrom při aktivaci a zpráva performApply při deaktivaci. Tímto způsobem struktura karet konfigurace spuštění poskytovala komunikaci mezi kartami prostřednictvím konfigurace spuštění (při opuštění karty se aktualizovala konfigurace s použitím aktuálních hodnot atributů a aktualizovala se karta, do níž se právě vstoupilo). Protože však mnoho karet komunikaci mezi kartami neprovádí, může to být neefektivní. Rovněž nebyla možnost rozlišit mezi kartou, která se aktivuje, a kartou, která poprvé zobrazuje zvolenou konfiguraci spuštění. Nově přidané metody kartám umožňují rozeznávat mezi aktivací a inicializací a mezi deaktivací a ukládáním aktuálních hodnot.

Výchozí implementace metody activated, kterou poskytuje abstraktní karta, volá metodu initializeFrom. Výchozí implementace metody deactivated volá performApply. Karty, které chtějí využít výhod nového rozhraní API, by měly podle potřeby tyto metody předefinovat. Obecný doporučený přístup pro karty, které neprovádí komunikaci mezi kartami, je tyto metody znovu implementovat tak, aby nic nedělaly.

Bod rozšíření launchConfigurationTabGroup (balíček org.eclipse.debug.ui)

V předchozích verzích se přepínání perspektiv uvádělo v konfiguraci spuštění prostřednictvím atributů konfigurace spuštění ATTR_TARGET_DEBUG_PERSPECTIVE a ATTR_TARGET_RUN_PERSPECTIVE. Po přidání rozšiřitelných režimů spuštění ve verzi 3.0 není tento přístup nadále přizpůsobitelný. Přepínání perspektiv se nyní uvádí na základě typu konfigurace spuštění podle režimu spuštění, který konfigurace spuštění podporuje. Do třídy DebugUITools bylo přidáno rozhraní API pro nastavení a získání perspektivy přidružené k typu konfigurace spuštění pro konkrétní režim spuštění.

Do bodu rozšíření launchConfigurationTabGroup se přidal nový volitelný prvek launchMode, který umožňuje vložené skupině karet určit výchozí perspektivu pro režim a typ konfigurace spuštění.

Uživatelé mohou upravit perspektivu přidruženou k typu konfigurace spuštění z uživatelského rozhraní platformy Eclipse tak, že otevřou dialogové okno konfigurace spuštění a vyberou uzel typu konfigurace spuštění ze stromu (místo individuální konfigurace). Zobrazí se karta, která uživateli umožňuje nastavit perspektivu pro každý podporovaný režim spuštění.

[Pouze JDT] IVMRunner (balíček org.eclipse.jdt.launching)

Do třídy VMRunnerConfiguration byly přidány dvě metody pro podporu nastavování a načítání proměnných prostředí. Implementátory rozhraní IVMRunner by měly volat VMRunnerConfiguration.getEnvironment() a toto prostředí předat spuštěnému prostředí JVM. Klienti, kteří používají DebugPlugin.exec(String[] cmdLine, File workingDirectory), to mohou místo toho udělat zavoláním DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp). Postačí jednoduché předání výsledku z getEnvironment().

[Pouze JDT] Třídy VMRunnerConfiguration a Bootstrap (balíček org.eclipse.jdt.launching)

V předchozích verzích měla třída VMRunnerConfiguration jeden atribut pro popsání cesty zavedení systému. Atribut je kolekcí hodnot typu String, které se uvádějí v argumentu -Xbootclasspath. Do třídy WMRunnerConfiguration byly přidány tři nové atributy pro podporu prostředí JVM, která dovolují připojování na začátek a na konec cesty zavedení systému. Nové přidané metody/atributy jsou:

Starý atribut getBootClassPath() stále existuje a obsahuje úplnou cestu ekvivalentní těmto třem novým atributům. Nicméně objekty VMRunner, které podporují nové volby cesty zavedení systému, by měly využít nové atributy.

[Pouze JDT] Vylepšená podpora pracovních kopií (balíček org.eclipse.jdt.core)

Prostředky modelu Java pro pracovní kopie byly ve verzi 3.0 přepracovány a poskytují výrazně vylepšenou funkčnost. Před verzí 3.0 umožňoval Java model vytváření jednotlivých pracovních kopií kompilačních jednotek. Bylo možno provádět změny na pracovní kopii a později je potvrdit. Existovala podpora omezené analýzy pracovní kopie v kontextu zbytku Java modelu. Nicméně neexistoval způsob, jak by tyto analýzy mohly vzít v úvahu více než jednu z těchto pracovních kopií současně.

Změny ve verzi 3.0 umožňují vytvářet a spravovat sady pracovních kopií kompilačních jednotek a provádět analýzy za přítomnosti všech pracovních kopií v sadě. Například je nyní možné, aby klient podobný opětovné deklaraci JDT vytvořil pracovní kopie jedné nebo více kompilačních jednotek, u kterých zvažuje změny, a pak mezi pracovními kopiemi vyřešil typové závislosti. To bylo dříve možné pouze poté, co byly změny v pracovních kopiích kompilačních jednotek potvrzeny.

Rozhraní API Java modelu si pro přidání této vylepšené podpory vyžádalo dvě změny:

(1) Funkčnost, která se dříve nacházela v rozhraní IWorkingCopy a dědilo ji rozhraní ICompilationUnit, se sloučila do rozhraní ICompilationUnit. Rozhraní IWorkingCopy se používalo pouze v tomto jednom místě a bylo mnohem obecnější, než bylo třeba. Tato změna rozhraní API zjednodušuje. Rozhraní IWorkingCopy je nyní nepřípustné. Další místa v rozhraní API, kde se IWorkingCopy používá jako parametr nebo typ výsledku, jsou nyní rovněž nepřípustná; náhradní metody rozhraní API zmiňují místo IWorkingCopy rozhraní ICompilationUnit.

(2) Rozhraní IBufferFactory bylo nahrazeno třídou WorkingCopyOwner. Vylepšená podpora pracovních kopií vyžaduje, aby existoval objekt, který pracovní kopie vlastní. Ačkoliv je IBufferFactory na správném místě, název nedává patřičně najevo, jak nový mechanizmus pracovních kopií funguje. Název WorkingCopyOwner naznačuje mnohem více. Kromě toho se WorkingCopyOwner deklaruje jako abstraktní třída, nikoliv rozhraní, aby se koncept vlastníka pracovní kopie mohl v budoucnu dále rozvíjet. Jediná metoda rozhraní IBufferFactory se beze změny přesunula do třídy WorkingCopyOwner. Třída WorkingCopyOwner neimplementuje rozhraní IBufferFactory, aby bylo zřejmé, že IBufferFactory je záležitostí minulosti. Rozhraní IBufferFactory je nyní nepřípustné. Další místa v rozhraní API, kde se IBufferFactory objevuje jako parametr nebo typ výsledku, jsou nyní rovněž nepřípustná; náhradní metody rozhraní API zmiňují místo rozhraní IBufferFactory třídu WorkingCopyOwner.

Tyto změny nenarušují binární kompatibilitu.

Při migraci by se všechny odkazy na typ IWorkingCopy měly místo toho odkazovat na ICompilationUnit. Jediná implementace rozhraní IWorkingCopy implementuje rovněž ICompilationUnit, což znamená, že objekty typu IWorkingCopy lze bezpečně přetypovat na ICompilationUnit.

Třídu, která implementuje IBufferFactory, bude třeba nahradit podtřídou třídy WorkingCopyOwner. Ačkoliv třída WorkingCopyOwner sama neimplementuje rozhraní IBufferFactory, bylo by možné deklarovat podtřídu třídy WorkingCopyOwner, která implementuje IBufferFactory a tudíž vytváří most mezi starým a novým přístupem (IBufferFactory deklaruje createBuffer(IOpenable), zatímco WorkingCopyOwner deklaruje createBuffer(ICompilationUnit); ICompilationUnit rozšiřuje IOpenable).

Protože změny zahrnující IWorkingCopy a IBufferFactory jsou navzájem provázané, doporučujeme se jimi zabývat současně. Podrobnosti o nepřípustnostech následují:

Restrukturalizace modulu plug-in org.eclipse.help

Modul plug-in org.eclipse.help, který udržuje rozhraní API a body rozšíření pro přispívání do systému nápovědy a jeho rozšiřování a také pro zobrazování nápovědy, nyní obsahuje pouze rozhraní API a body rozšíření pro přispívání do prostředků nápovědy a přístup k nim. Část výchozí implementace uživatelského rozhraní nápovědy obsažená v tomto modulu plug-in byla přesunuta do nového modulu plug-in org.eclipse.help.base spolu s rozhraními API pro rozšiřování implementace. Rozhraní API a bod rozšíření pro přispívání do uživatelského rozhraní nápovědy a zobrazování nápovědy se přesunuly do modulu plug-in org.eclipse.ui. Tato restrukturalizace umožňuje aplikacím větší tvárnost s ohledem na systém nápovědy; nová struktura umožňuje aplikacím založeným na obecné pracovní ploše poskytovat jejich vlastní uživatelské rozhraní nápovědy a implementaci nápovědy, nebo systém nápovědy úplně vynechat.

Protože ovlivněné body rozšíření a balíčky API jsou určeny pouze pro použití samotným systémem nápovědy, je nepravděpodobné, že by tato změna ovlivnila stávající moduly plug-in. Zde jsou uvedeny pouze pro úplnost:

Nové API pro uživatelské rozhraní hledání

Ve verzi 3.0 bylo přidáno nové rozhraní API pro implementaci přizpůsobeného vyhledávání. Původní rozhraní API je ve verzi 3.0 nepřípustné a doporučujeme portovat klienty na nové rozhraní API v balíčcích org.eclipse.search.ui a org.eclipse.search.ui.text.

Klienti budou muset vytvořit implementace rozhraní ISearchQuery, ISearchResult a ISearchResultPage. Implementací ISearchResultPage je pak třeba přispět do nového bodu rozšíření org.eclipse.search.searchResultViewPages.

Výchozí implementace rozhraní ISearchResult a ISearchResultPage poskytuje balíček org.eclipse.search.ui.text.

Prázdné zprávy v MessageBox a DirectoryDialog (balíček org.eclipse.swt.widgets)

Před verzí 3.0 bylo výsledkem volání metod SWT DirectoryDialog.setMessage(String string) nebo MessageBox.setMessage(String string) s prázdnou hodnotou parametru string dialogové okno bez textu v titulku. Toto chování nebylo specifikováno (předání hodnoty null nebylo nikdy povoleno) a přináší problémy s metodou getMessage, která nesmí vrátit hodnotu null. Ve verzi 3.0 nyní předání hodnoty null vyvolá výjimku IllegalArgumentException; specifikace byly změněny, aby toto obsahovaly a uvedly do souladu s metodou supertřídy Dialog.setMessage. Pokud používáte Dialog.setMessage, zajistěte, aby předávaný řetězec nikdy neměl hodnotu null. Chcete-li zobrazit dialogové okno bez textu v titulku, jednoduše předejte prázdný řetězec.

Zlepšení modální zpětné vazby o průběhu

Podpora souběžných operací vyžaduje důmyslnější způsoby, jak zobrazit modální průběh. Jako součást úsilí o zlepšení odezvy byla implementována dodatečná podpora indikace průběhu ve třídě IProgressService. Stávající způsob zobrazování indikace průběhu pomocí třídy ProgressMonitorDialog stále funguje. Avšak pro zlepšení zkušeností uživatele doporučujeme migrovat na IProgressService.

Dokument Zobrazování modální indikace průběhu v Eclipse 3.0 popisuje, jak migrovat na nový způsob používající IProgressService.

Skupiny akcí ladění odebrány

Bod rozšíření pro skupiny akcí ladění (org.eclipse.debug.ui.debugActionGroups) byl odebrán. V Eclipse 3.0 pracovní plocha zavedla podporu aktivit prostřednictvím bodu rozšíření org.eclipse.platform.ui.activities. Tato podpora rovněž poskytuje vše, co poskytovaly skupiny akcí ladění, rovněž se snáze používá (místo úplného určení všech jednotlivých akcí podporuje vzory) a pro svou podporu má programové rozhraní API. Neodebrání odkazů na starý bod rozšíření nezpůsobí žádná selhání. Odkazy na bod rozšíření se budou jednoduše ignorovat. Dodavatelům produktů doporučujeme, aby pro přiřazování akcí ladění specifických pro jazyk k aktivitám specifickým pro jazyk používali podporu aktivit pracovní plochy (například akce ladění pro jazyk C++ se mohou asociovat s aktivitou nazvanou "Vývoj C++").

BreakpointManager může být znepřístupněn

Rozhraní IBreakpointManager nyní definuje metody setEnabled(boolean) a isEnabled(). Když je správce bodů přerušení znepřístupněn, ladicí programy by měly ignorovat všechny registrované body přerušení. Platforma ladění rovněž poskytuje nový mechanizmus listenerů, IBreakpointManagerListener, který klientům umožňuje registrovat se u správce bodů přerušení a dostat upozornění, když se jeho zpřístupnění změní. Pohled Body přerušení volá toto rozhraní API z nové přepínací akce, která umožňuje uživateli "Přeskočit všechny body přerušení". Ladicí programy, které nedodržují zpřístupnění správce bodů přerušení, budou tedy vypadat poněkud narušené, pokud se uživatel pokusí tuto funkci použít.

[Pouze JDT] Účastníci hledání v kódu Java (balíček org.eclipse.jdt.core.search)

Jazyky blízké jazyku Java (např. JSP, SQLJ, JWS, atd.) by se měly být schopny účastnit hledání v kódu Java. Implementátory takových jazyků by konkrétně měly být schopny:

Takový implementátor se nazývá účastník hledání. Rozšiřuje třídu SearchParticipant. Účastníci hledání se předávají vyhledávacím dotazům (viz SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).

Pro indexaci nebo vyhledání shod musí účastník hledání definovat podtřídu třídy SearchDocument, která umí načíst obsah dokumentu, a to předefinováním buď getByteContents(), nebo getCharContents(). Instance této podtřídy se vrátí v getDocument(String).

Účastník hledání, který chce indexovat nějaký dokument, použije metodu SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) k naplánování indexace daného dokumentu do daného rejstříku. Jakmile je dokument připraven k indexování, základní rámec zavolá SearchParticipant.indexDocument(SearchDocument, IPath). Účastník hledání pak získá obsah dokumentu, zanalyzuje jej a přidá položky rejstříku pomocí metody SearchDocument.addIndexEntry(char[], char[]).

Jakmile je indexace hotova, lze se rejstříků dotazovat a vyhledávat shody pomocí metody SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Ta nejprve požádá každého účastníka hledání o rejstříky, které jsou pro tento dotaz potřebné, pomocí metody SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). Pro každou položku rejstříku, která vyhovuje danému vzoru, účastníka hledání požádá o vytvoření dokumentu hledání (viz getDocument(String)). Všechny tyto dokumenty se předají účastníku hledání, aby mohl nalézt shody pomocí locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). Účastník hledání upozorní SearchRequestor na nalezené shody pomocí acceptSearchMatch(SearchMatch) a předáním instance podtřídy třídy SearchMatch.

Účastník hledání může delegovat část své práce na výchozího účastníka hledání v kódu Java. Instance tohoto výchozího účastníka se získá pomocí SearchEngine.getDefaultSearchParticipant(). Je-li například účastník SQLJ požádán o nalezení shod, může ze svých dokumentů .sqlj vytvořit dokumenty .java a delegovat práci na výchozího účastníka tím, že mu předá dokumenty .java.