Nekompatibility mezi Eclipse 2.1 a 3.0

Platforma Eclipse se mezi verzemi 2.1 a 3.0 změnila nekompatibilním způsobem, který ovlivňuje moduly plug-in. Následující položky popisují oblasti, které se změnily, a poskytují pokyny pro migraci modulů plug-in pro verzi 2.1 do verze 3.0. Pokud máte problémy se spouštěním svých modulů plug-in pro verzi 2.1 ve verzi 3.0, vezměte na vědomí, že se stačí podívat pouze sem.

  1. Verze manifestu modulu plug-in
  2. Restrukturalizace modulů plug-in uživatelského rozhraní platformy
  3. Restrukturalizace modulů plug-in Platform Core Runtime
  4. Odebrání modulu plug-in Xerces
  5. Eclipse 3.0 je souběžnější
  6. Otevírání editorů na IFiles
  7. Přechod na značkovač v editoru
  8. Spouštěč editoru
  9. Registr editorů
  10. Registr nápovědy pro značkovač pracovní plochy
  11. Poskytovatelé dokumentů textového editoru
  12. Textové editory
  13. Podpora anotací bez hlavičky
  14. Pohled Konzola
  15. Listenery bodů přerušení Java
  16. Přístup ke schránce ve vláknu uživatelského rozhraní
  17. Události stisku kláves
  18. Procházení uživatelských obslužných prvků klávesou Tab
  19. Pořadí události výběru v prvcích widget SWT tabulka a strom
  20. Nová úroveň závažnosti v objektech stavů
  21. Upozornění na změnu prostředku související se sestavením
  22. Upozornění po dobu operací pracovního prostoru
  23. Rozšíření popisovače toku adres URL
  24. Pořadí zavádění tříd
  25. Doména ochrany zaváděče tříd není nastavena
  26. Přetypování objektů na PluginModel
  27. Nekompletní implementace ILibrary
  28. Neplatné předpoklady o formě adres URL
  29. Metody BootLoader přesunuty/odstraněny
  30. Export modulu plug-in nezahrnuje automaticky jeho soubory JAR
  31. Reexport rozhraní API běhové komponenty
  32. Metody třídy Platform pro analýzu modulů plug-in
  33. Knihovny modulů plug-in dodané fragmenty
  34. Změny ve skriptech sestavení
  35. Změny v úloze Ant sestavení PDE
  36. Změny v úloze Ant eclipse.build
  37. Změny v úloze Ant eclipse.fetch
  38. Náhrada souboru install.ini

1. Verze manifestu modulu plug-in

Hlavička souborů s manifesty pro moduly plug-in (a jejich fragmenty) se změnila a obsahuje nový řádek, který označuje verzi manifestu příslušného modulu plug-in. Před verzí 3.0 moduly plug-in tento řádek <?eclipse ...?> nenesly; od verze 3.0 jej musí vždy mít. Tato změna má běhové komponentě platformy Eclipse umožnit spolehlivě rozpoznat moduly plug-in pro verzi starší než 3.0, které byly přeneseny do verze 3.0, aby mohla takovým modulům plug-in automaticky poskytnout větší binární kompatibilitu. Toto je obecný formát souboru plugin.xml (soubor fragment.xml je podobný):

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

Manifesty modulů plug-in vytvořené prostředím PDE 3.0 mají automaticky tento formát. Doporučujeme použít nástroj pro migraci modulů plug-in v prostředí PDE. Tento nástroj automaticky vkládá označený řádek do manifestů modulů plug-in a fragmentů modulů plug-in pro verzi 2.1 a zaměřuje se na mnoho dalších změn, které jsou zde popsány.

Pokud tuto direktivu do souboru plugin.xml přidáte (ručně nebo pomocí PDE), je třeba soubor také aktualizovat, aby explicitně uváděl seznam modulů plug-in, na kterých závisí. Například před verzí Eclipse 3.0 byly závislosti na org.eclipse.core.runtime a org.eclipse.core.boot implicitní. Ve verzi 3.0 není org.eclipse.core.boot nadále zapotřebí a vývojáři musí zvolit podle potřeby org.eclipse.core.runtime nebo org.eclipse.core.runtime.compatibility (nebo nic z toho).

Poznámka: Toto je jedna z nekompatibilit, která neovlivňuje způsob, jak Eclipse 3.0 spouští binární moduly plug-in pro verzi 2.1.

2. Restrukturalizace modulů plug-in uživatelského rozhraní platformy

Modul plug-in org.eclipse.ui, který býval hlavním modulem plug-in uživatelského rozhraní platformy, nyní poskytuje pouze rozhraní API a body rozšíření pro obecnou pracovní plochu (tj. nespecifickou pro konkrétní IDE). Rozhraní API a body rozšíření, které jsou specifické pro IDE nebo volitelné, se přesunuly do jiných modulů plug-in.

Dopad této změny je dvojí: (1) Přesunuté body rozšíření z org.eclipse.ui mají nové ID bodů rozšíření a (2) změnil se seznam požadovaných modulů plug-in.

Body rozšíření org.eclipse.ui v následující tabulce se přesunuly do jiných modulů plug-in, takže se jejich ID bodů rozšíření změnily. Pokud stávající modul plug-in přispívá nějakým rozšířením do přesunutých bodů rozšíření, pak se musí změnit odkaz v atributu "point" prvku <extension> v souboru s manifestem modulu plug-in, aby se odkazoval na odpovídající nové ID bodů rozšíření. Nástroj pro migraci modulů plug-in v prostředí PDE tyto opravy provádí.

Poznámka: Toto je jedna z nekompatibilit, která neovlivňuje způsob, jak Eclipse 3.0 spouští binární moduly plug-in pro verzi 2.1. Běhová komponenta Eclipse 3.0 automaticky detekuje moduly plug-in pro verzi starší než 3.0 (podle chybějícího výše zmíněného řádku <?eclipse version="3.0"?> v manifestu modulu plug-in) a automaticky kompenzuje tyto změny bodů rozšíření a závislostí modulů plug-in.

Staré ID bodu rozšíření

Nové ID bodu rozšíření

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

Následující tabulka uvádí balíčky rozhraní API, které dříve poskytoval modul plug-in org.eclipse.ui a které se přesunuly do jiných modulů plug-in. (Názvy balíčků, tříd, polí a metod rozhraní API se nezměnily.) V některých případech jsou nyní balíčky rozhraní API rozděleny do více modulů plug-in. Protože třídy rozhraní API viditelné pro daný modul plug-in jsou určeny seznamem požadovaných modulů plug-in tohoto modulu, mohou tyto změny vyžadovat úpravu prvků "<requires>" v manifestu stávajícího modulu plug-in, aby se obnovil přístup ke třídě rozhraní API.

Tato změna ovlivňuje pouze moduly plug-in, které závisí na modulu plug-in org.eclipse.ui (tj. obsahují <import plugin="org.eclipse.ui"/> v sekci <requires> manifestu modulu plug-in); žádné jiné moduly plug-in nejsou ovlivněny. Pokud je váš modul plug-in ovlivněn, možná budete muset změnit prvek <import>, nebo přidat další prvky <import>, aby všechny třídy rozhraní API, které váš modul plug-in potřebuje, byly v oboru. Doporučujeme, aby moduly plug-in uváděly závislosti pouze na modulech plug-in, které skutečně používají. Zahrnutí nepotřebných závislostí snižuje výkon v době provádění, protože zaváděč tříd Java musí hledat třídy ve všech závislých modulech. (Nástroj pro migraci modulů plug-in v prostředí PDE opraví závislosti a pomůže určit minimální množinu.)

Balíček rozhraní API

Modul plug-in verze 2.1

Odpovídající modul(y) plug-in verze 3.0

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

3. Restrukturalizace modulů plug-in Platform Core Runtime

Běhová komponenta platformy Eclipse 3.0 je založena na OSGi, což si vynutilo změny ve struktuře dvou modulů plug-in běhové komponenty platformy, a to org.eclipse.core.runtime a org.eclipse.core.boot.

Nový modul plug-in org.eclipse.core.runtime.compatibility poskytuje implementační můstek mezi starými a novými rozhraními API a je novým domovem pro mnoho zastaralých rozhraní API, která se dříve nacházela v org.eclipse.core.runtime a org.eclipse.core.boot. Body rozšíření běhové komponenty platformy nejsou restrukturalizací ovlivněny.

Při migraci stávajícího modulu plug-in do verze 3.0 je třeba aktualizovat manifest modulu plug-in, aby odrážel novou strukturu modulů plug-in běhové komponenty platformy Eclipse. Nástroj pro migraci manifestů modulů plug-in v prostředí PDE v případě potřeby přidá závislost na org.eclipse.core.runtime.compatibility.

Rovněž vezměte na vědomí, že pokud svůj modul plug-in označíte jako 3.0 (pomocí <?eclipse version="3.0"?>) a váš modul plug-in definuje třídu Plugin, musíte buď explicitně provést <import plugin="org.eclipse.core.runtime.compatibility"/> v manifestu modulu plug-in, nebo zajistit, aby třída modulu plug-in definovala výchozí konstruktor.

Poznámka: Toto je jedna z nekompatibilit, která neovlivňuje způsob, jak Eclipse 3.0 spouští binární moduly plug-in pro verzi 2.1. Běhová komponenta Eclipse 3.0 automaticky detekuje moduly plug-in pro verzi starší než 3.0 (podle chybějícího řádku <?eclipse version="3.0"?> v manifestu modulu plug-in) a automaticky kompenzuje tyto změny běhové komponenty platformy.

4. Odebrání modulu plug-in Xerces

Modul plug-in org.eclipse.xerces není nadále potřebný a byl odstraněn. Podpora analýzy XML je zabudována do J2SE 1.4 a přítomnost modulu plug-in Xerces způsobuje konflikty zaváděče tříd. Balíčky rozhraní API javax.xml.parsers, org.w3c.dom.* a org.xml.sax.*, které původně poskytoval modul plug-in org.eclipse.xerces, jsou nyní dostupné z knihoven J2SE.

Pokud váš modul plug-in vyžaduje modul plug-in org.eclipse.xerces, musíte změnit manifest svého modulu plug-in a tuto uvedenou závislost odebrat. Jakmile se to provede, měl by se kód modulu plug-in zkompilovat a spustit bez dalších změn.

Binárním modulům plug-in pro verzi 2.1 s uvedenou závislostí na modulu plug-in org.eclipse.xerces bude při spuštění ve standardní konfiguraci Eclipse 3.0 chybět nezbytný předpoklad. Následkem toho se modul plug-in nebude aktivovat.

5. Eclipse 3.0 je souběžnější

Před verzí Eclipse 3.0 pracovala platforma Eclipse většinou v jediném vláknu. Většina metod a bodů rozšíření rozhraní API pracovala buď ve vláknu uživatelského rozhraní, nebo ve vláknu, které se oddělilo od dialogu průběhu, jenž zablokoval vlákno uživatelského rozhraní. Většina tvůrců modulů plug-in se nemusela příliš zabývat bezpečností vláken, kromě zajištění, aby se veškerá aktivita uživatelského rozhraní vyskytovala ve vláknu uživatelského rozhraní. V Eclipse 3.0 je obecně mnohem více souběžnosti. Mnoho operací se nyní vyskytuje ve vláknu na pozadí, kde mohou běžet souběžně s jinými vlákny, včetně vlákna uživatelského rozhraní. Všechny moduly plug-in, jejichž kód běží ve vláknu na pozadí, si musí být nyní ve svém kódu vědomy bezpečnosti vláken.

Kromě modulů plug-in, které explicitně spouští operace na pozadí s použitím rozhraní API org.eclipse.core.runtime.jobs, existuje několik systémových prostředků rozhraní API a bodů rozšíření platformy, které využívají vlákna na pozadí. Moduly plug-in, které se do těchto systémových prostředků zapojují, musí zajistit, aby jejich kód byl vzhledem k vláknům bezpečný. Následující tabulka shrnuje rozhraní API a body rozšíření, které v Eclipse 3.0 spouští svůj kód nebo jeho část ve vláknu na pozadí:

Bod rozšíření nebo třída rozhraní API

Poznámky

org.eclipse.core.runtime.IRegistryChangeListener Nové v Eclipse 3.0, běží na pozadí
org.eclipse.core.resources.IResourceChangeListener Události AUTO_BUILD nyní na pozadí
org.eclipse.core.resources.builders (bod rozšíření) Automatické sestavení nyní na pozadí
org.eclipse.core.resources.ISaveParticipant SNAPSHOT nyní na pozadí
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (bod rozš.) Nové v Eclipse 3.0, běží na pozadí
org.eclipse.ui.decorators (bod rozšíření) Na pozadí již v Eclipse 2.1
org.eclipse.ui.startup (bod rozšíření) Na pozadí již v Eclipse 2.1
org.eclipse.team.core.org.eclipse.team.core.repository (bod rozšíření) Mnoho operací nyní na pozadí
org.eclipse.team.ui.synchronizeParticipants (bod rozšíření) Nové v Eclipse 3.0, běží na pozadí
org.eclipse.debug.core.launchConfigurationTypes (bod rozšíření) Nyní běží na pozadí
org.eclipse.jdt.core.IElementChangedListener Událost ElementChangedEvent.PRE_AUTO_BUILD nyní běží na pozadí, POST_RECONCILE již na pozadí běžela

Existují různé strategie pro zajištění, aby kód neporušoval vlákna. Naivním řešením je zajistit, aby se všechna práce vykonávala ve vláknu uživatelského rozhraní, čímž se zajistí serializované provádění. To je běžný přístup pro moduly plug-in uživatelského rozhraní, které neprovádí zpracování náročné na procesor. Pokud tak postupujete, buďte si vědomi rizika zablokování, které spočívá v Display.syncExec. Display.asyncExec je obecně bezpečnější, neboť nezanáší riziko zablokování, ale za cenu ztráty přesné kontroly nad tím, kdy se kód provede.

Další techniky pro zajištění neporušenosti vláken v kódu zahrnují:

6. Otevírání editorů na IFiles

Následující metody byly odstraněny z rozhraní org.eclipse.ui.IWorkbenchPage. IWorkbenchPage se deklaruje v obecné pracovní ploše, ale metody jsou inherentně specifické pro prostředky.

Klienti těchto metod IWorkbenchPage.openEditor by měli místo nich volat odpovídající veřejné statické metody deklarované ve třídě org.eclipse.ui.ide.IDE (v modulu plug-in org.eclipse.ui.ide).

Klienti těchto metod IWorkbenchPage.openSystemEditor(IFile) by měli převést IFile na IEditorInput pomocí nového FileEditorInput(IFile) a poté zavolat metodu openEditor(IEditorInput,String). Jinými slovy, přepište page.openSystemEditor(file) na page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Poznámka: Klienti, kteří používají ID editoru IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID, musí předat vstup editoru, který implementuje org.eclipse.ui.IPathEditorInput (což FileEditorInput dělá).

Poznámka: Toto je jedna z nekompatibilit, která neovlivňuje způsob, jak Eclipse 3.0 spouští binární moduly plug-in pro verzi 2.1. Eclipse 3.0 obsahuje mechanizmus binární běhové kompatibility, který zajišťuje, že stávající binární moduly plug-in pro verzi 2.1 používající libovolné z odstraněných metod openEditor a openSystemEditor nadále fungují jako ve verzi 2.1, navzdory této změně v rozhraní API. (Odstraněné metody se efektivně "zpětně přidají" pomocí fragmentu org.eclipse.ui.workbench.compatibility.)

7. Přechod na značkovač v editoru

Následující metoda byla odstraněna z rozhraní org.eclipse.ui.IEditorPart. IEditorPart se deklaruje v obecné pracovní ploše, ale metoda je inherentně specifická pro prostředky.

Odpovídající metody byly rovněž odstraněny ze tříd v balíčku org.eclipse.ui.part, které implementují IEditorPart, jmenovitě EditorPart, MultiEditor, MultiPageEditorPart a MultiPageEditor. 

Klienti, kteří volají tuto metodu, by místo toho měli testovat, zda část editoru implementuje nebo se přizpůsobuje rozhraní org.eclipse.ui.ide.IGotoMarker (v modulu plug-in org.eclipse.ui.ide), a pokud ano, zavolat gotoMarker(IMarker). Třída IDE má pro tento účel pohodlnou metodu: IDE.gotoMarker(editor, marker);

Klienti implementující editor, který může sám sebe umístit podle informací v objektu IMarker, by měli implementovat nebo se přizpůsobit rozhraní org.eclipse.ui.ide.IGotoMarker.

Protože metoda gotoMarker(IMarker) je jedinou metodou rozhraní IGotoMarker a má stejný podpis a specifikaci jako stará metoda IEditorPart.gotoMarker(IMarker), mohou se stávající implementace editorů této změně jednoduše přizpůsobit zahrnutím IGotoMarker do klauzule implements v definici třídy.

Binární moduly plug-in pro verzi 2.1 s kódem, který volá tuto metodu, při spuštění ve standardní konfiguraci Eclipse 3.0 obdrží výjimku chyby při sestavování tříd.

8. Spouštěč editoru

Rozhraní spouštěče editoru, org.eclipse.ui.IEditorLauncher, implementují moduly plug-in, které přispívají externími editory. Následující metoda byla z tohoto rozhraní odebrána. Rozhraní IEditorLauncher se deklaruje v obecné pracovní ploše, ale metoda je inherentně specifická pro prostředky.

Byla nahrazena metodou

Klienti, kteří volají metodu IEditorLauncher.open(file), by měli místo ní volat IEditorLauncher.open(file.getLocation()). Klienti, kteří implementují toto rozhraní, by měli nahradit svou implementaci metody open(IFile) implementací open(IPath), nebo ji o ni rozšířit.

Binární moduly plug-in pro verzi 2.1 s kódem, který volá tuto metodu, při spuštění ve standardní konfiguraci Eclipse 3.0 obdrží výjimku chyby při sestavování tříd.

9. Registr editorů

Následující metody byly odstraněny z rozhraní org.eclipse.ui.IEditorRegistry. Rozhraní IEditorRegistry se deklaruje v obecné pracovní ploše, ale metoda je inherentně specifická pro prostředky.

Klienti, kteří volají getEditors(file) nebo getImageDescriptor(file), by měli volat ekvivalentní metody typu "String": Klienti, kteří volají setDefaultEditor(IFile file, String editorId) a getDefaultEditor(IFile file), by měli místo toho volat odpovídající veřejné statické metody deklarované ve třídě org.eclipse.ui.ide.IDE (v modulu plug-in org.eclipse.ui.ide): Kontrakt rozhraní API pro metodu IEditorRegistrygetDefaultEditor() se rovněž změnil. Tato metoda je nyní také nepřípustná a vždy vrátí deskriptor externího systémového editoru, System External Editor. Tato změna má dopad na klienty, kteří předpokládají, že výchozím vráceným editorem je textový editor.

Existují nové konstanty, které reprezentují identifikátory externího systémového editoru a systémového editoru na místě(SYSTEM_EXTERNAL_EDITOR_ID a SYSTEM_INPLACE_EDITOR_ID). Tyto dva editory vyžadují vstup editoru, který implementuje nebo se přizpůsobuje rozhraní org.eclipse.ui.IPathEditorInput. Vezměte na vědomí, že deskriptor editoru na místě nebude existovat v konfiguracích Eclipse, které nepodporují editování na místě.

10. Registr nápovědy pro značkovač pracovní plochy

Následující metoda byla odstraněna z rozhraní org.eclipse.ui.IWorkbench. Rozhraní IWorkbench se deklaruje v obecné pracovní ploše, ale metoda je inherentně specifická pro prostředky.

Klienti IWorkbench.getMarkerHelpRegistry() by měli místo toho volat veřejnou statickou metodu org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (v modulu plug-in org.eclipse.ui.ide).

Binární moduly plug-in pro verzi 2.1 s kódem, který volá tuto metodu, při spuštění ve standardní konfiguraci Eclipse 3.0 obdrží výjimku.

11. Poskytovatelé dokumentů textového editoru

Aby byl org.eclipse.ui.texteditor.AbstractTextEditor nezávislý na IFile, zavádí org.eclipse.ui.texteditor.AbstractDocumentProvider koncept operace poskytovatele dokumentů (DocumentProviderOperation) a spouštěče operace poskytovatele dokumentů (IRunnableContext). Při požadavku na provedení vynulování, uložení nebo synchronizace vytvoří AbstractDocumentProvider operace poskytovatele dokumentů a použije spouštěč operací k jejich provedení. Kontext procesu runnable lze poskytnout pomocí podtříd prostřednictvím metody getOperationRunner. Zde je shrnutí změn, kterým se klienti musí přizpůsobit:

Podtřída org.eclipse.ui.editors.text.StorageDocumentProvider třídy AbstractDocumentProvider implementuje metodu getOperationRunner tak, že vždy vrací hodnotu null. To znamená, že podtřídy třídy StorageDocumentProvider by tato změna neměla ovlivnit.

Podtřída org.eclipse.ui.editors.text.FileDocumentProvider třídy StorageDocumentProvider implementuje metodu getOperationRunner, která vrací kontext IRunnableContext pro provedení daných operací DocumentProviderOperations uvnitř operace WorkspaceModifyOperation. Další změny třídy FileDocumentProvider jsou:

12. Textové editory

Změny v org.eclipse.ui.texteditor.AbstractTextEditor:

Podtřída org.eclipse.ui.texteditor.StatusTextEditor třídy AbstractTextEditor poskytuje predikátovou metodu isErrorStatus(IStatus). Podtřídy ji mohou předefinovat, aby mohly rozhodnout, zda se daný stav musí považovat za chybu či nikoliv.

Změny v org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:

13. Podpora anotací bez hlavičky

Jako součást zavedení podpory anotací bez hlavičky byly provedeny následující změny ve třídě Annotation:

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

14. Pohled Konzola

Eclipse 3.0 má novou podporu obecné konzoly. Obecná konzola je dostupná prostřednictvím nabídky Okno > Zobrazit pohled > Základní > Konzola a používá se pro ladění v platformě Eclipse a integraci Ant.

ID pohledu pro konzolu se rovněž změnil z org.eclipse.debug.ui.ConsoleView na org.eclipse.ui.console.ConsoleView. Moduly plug-in pro verzi 2.1, které programově otevírají konzolu, nebudou úspěšné, protože starý pohled nadále neexistuje.

15. Listenery bodů přerušení Java

Ve verzi 3.0 se návratové typy metod org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) a installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) změnily z logické hodnoty na celé číslo, aby listenery mohly dát hlas "nezáleží". Ve verzích před 3.0 mohly listenery pouze hlasovat pro "pozastavit" nebo "nepozastavit", když bylo dosaženo bodu přerušení, a "instalovat" nebo "neinstalovat" před instalací bodu přerušení. Ve verzi 3.0 mohou listenery rovněž pro každé z těchto upozornění hlasovat "nezáleží". To klientům umožňuje rozhodovat pouze v situacích, které je zajímají. Pro upozornění "bod přerušení dosažen" způsobí bod přerušení pozastavení, pokud libovolné listenery hlasují "pozastavit", nebo pokud všechny listenery hlasují "nezáleží"; nezpůsobí pozastavení, pokud alespoň jeden listener hlasuje "nepozastavit" a žádný listener nehlasuje "pozastavit". Podobně pro upozornění "bod přerušení se instaluje" se bod přerušení nainstaluje, pokud libovolný listener hlasuje pro instalaci, nebo pokud všechny listenery hlasují "nezáleží"; nenainstaluje se, pokud alespoň jeden listener hlasuje "neinstalovat" a žádný listener nehlasuje "instalovat". Obecně by implementátory měly vrátit DONT_CARE, pokud nejsou silně přikloněny na jednu nebo na druhou stranu. Je důležité mít například na paměti, že hlas "pozastavit" potlačí hlasy "nepozastavit" od všech ostatních listenerů.

Rozhraní IJavaBreakpointListener implementují klienti, kteří vytvářejí nebo reagují na body přerušení v kódu v jazyce Java. Pravděpodobně existuje jen několik klientů kromě JDT samotného, nepočítaje klienta, jenž problém oznámil (chyba 37760), kterým tato změna pomůže. Tato změna naruší stávající kód, který implementuje rozhraní IJavaBreakpointListener. Tento kód je třeba upravit, aby vracel příslušnou celočíselnou hodnotu, než jej bude možno zkompilovat a spustit ve verzi 3.0.

16. Přístup ke schránce ve vláknu uživatelského rozhraní

Před verzí 3.0 bylo metodám třídy SWT org.eclipse.swt.dnd.Clipboard tiše dovoleno běžet v jiných vláknech než ve vláknu uživatelského rozhraní. Toto přehlédnutí vedlo k selháním na GTK, kde operační systém vyžaduje, aby všechny interakce se schránkou probíhaly ve vláknu uživatelského rozhraní. Toto přehlédnutí nebylo odhaleno dříve, neboť mnoho aplikací běží jen v jednom vláknu a většina jejich testování probíhá na Windows. Aby bylo rozhraní API schránky udržitelné a meziplatformní, ve verzi 3.0 se specifikace a implementace všech metod rozhraní API schránky změnila tak, že vyvolají výjimku SWT (ERROR_THREAD_INVALID_ACCESS), pokud jsou vyvolány z jiného vlákna než vlákna uživatelského rozhraní. Komponenty Eclipse, například textový editor, běžně poskytují služby schránky automaticky, což mnoho klientů izoluje od této důležité změny. Stávající kód, který přímo používá schránku, by měl zajistit, aby byly metody rozhraní API volány ve správném vláknu, a to použitím Display.asyncExec nebo syncExec podle potřeby k přesunutí přístupů do vlákna uživatelského rozhraní.

17. Události stisku kláves

Ve verzi 3.0 SWT oznamuje události stisku kláves předtím, než se zpracují v operačním systému. To je mnohem dříve, než ve verzích před verzí 3.0. Tato změna byla provedena pro podporu vazeb kláves v Eclipse, což vyžaduje zachytávání událostí kláves předtím, než má kterýkoliv prvek widget možnost znak zpracovat. Důsledky této změny vidí kód, který přímo zpracovává nízkoúrovňové události org.eclipse.swt.SWT.KeyDown. Například to znamená, že když listener na prvku widget Text přijme událost stisku klávesy, obsah prvku widget (getText()) nebude dosud obsahovat právě napsaný znak (před verzí 3.0 by obsahoval). Doporučeným způsobem, jak z prvku widget získat plný text včetně aktuální klávesy, je zpracovat události vyšší úrovně SWT.Modify nebo SWT.Verify místo nízkoúrovňové události SWT.KeyDown event; kód, který již takto pracuje, není touto změnou ovlivněn.

18. Procházení uživatelských obslužných prvků klávesou Tab

Když byl před verzí 3.0 fokus ve třídě SWT org.eclipse.swt.widgets.Canvas nebo jedné z jejích podtříd (včetně uživatelských prvků widget), stiskem Ctrl+Tab, Shift+Tab, Ctrl+PgUp nebo Ctrl+PgDn se automaticky spustil průchod na další/předchozí prvek widget bez ohlášení události klávesy. Toto chování bylo nespecifikováno a jde proti pravidlu, že plátna (objekty Canvas) vidí každou klávesu, která se uvnitř nich stiskne. Správný způsob, jak procházení ošetřit, je registrovat na průchod listener. Pro správnou podporu vazeb kláves platformy Eclipse se ve verzi 3.0 výchozí chování změnilo tak, že plátno nyní místo procházení vidí události kláves Ctrl+Tab, Shift+Tab, Ctrl+PgUp a Ctrl+PgDn. Pokud používáte přímo Canvas nebo definujete podtřídu třídy Canvas, zkontrolujte, zda registrujete listener procházení.

19. Pořadí události výběru v prvcích widget SWT tabulka a strom

Výběry myší na položkách ve třídách SWT org.eclipse.swt.widgets.Table a Tree generují posloupnost událostí MouseDown-Selection-MouseUp jednotně ve všech operačních prostředích. Podobně výběry klávesnicí generují sekvenci událostí KeyDown-Selection-KeyUp jednotně ve všech operačních prostředích. Před verzí 3.0 nebylo pořadí událostí jednotné, přičemž prostředí Motif a Photon se oproti ostatním lišila tím, že vždy ohlašovala událost výběru (Selection) jako první; tj. Selection-MouseDown-MouseUp nebo Selection-KeyDown-KeyUp. Ve verzi 3.0 bylo pořadí událostí v prostředích Motif a Photon změněno, aby se shodovalo s ostatními. Stávající kód, který správně fungoval na {Windows, GTK} i na {Motif, Photon}, pravděpodobně nebude ovlivněn. Ale je prozíravé zkontrolovat svůj kód, zda se nespoléhá na neplatné pořadí událostí.

20. Nová úroveň závažnosti v objektech stavů

org.eclipse.core.runtime.IStatus má novou konstantu závažnosti, IStatus.CANCEL, kterou lze použít k označení zrušení. Volání metody IStatus.getSeverity(), při kterých se spoléhá na to, že množina možných závažností se omezuje na IStatus.OK, INFO, WARNING a ERROR, jsou tímto přídavkem ovlivněna. Volající, kteří volají metodu getSeverity, by měli aktualizovat svůj kód, aby obsahoval novou závažnost.

21. Upozornění na změnu prostředku související se sestavením

V Eclipse 3.0 se nyní automatická sestavení pracovního prostoru vyskytují ve vláknu na pozadí. To vyžadovalo změnu kontraktu API v org.eclipse.core.resources.IResourceChangeEvent. Kontrakt rozhraní IResourceChangeEvent předtím zaručoval následující pořadí událostí pro všechny změny pracovního prostoru:

  1. Případné upozornění na událost PRE_DELETE nebo PRE_CLOSE
  2. Provedení operace
  3. Upozornění na událost PRE_AUTO_BUILD
  4. Je-li automatické sestavení zapnuto, provedení přírůstkového sestavení pracovního prostoru
  5. Upozornění na událost POST_AUTO_BUILD
  6. Upozornění na událost POST_CHANGE

Protože automatické sestavení nyní běží na pozadí, nelze nadále zaručit časový vztah mezi událostmi AUTO_BUILD a událostí POST_CHANGE. V Eclipse 3.0 jsou z činnosti odebrány kroky 3-5 výše uvedené struktury. Výsledný obrázek vypadá takto:

  1. Případné upozornění na událost PRE_DELETE nebo PRE_CLOSE
  2. Provedení operace
  3. Upozornění na událost POST_CHANGE

Platforma pravidelně provádí operaci sestavení pracovního prostoru na pozadí. Vezměte na vědomí, že k tomu dochází bez ohledu na to, zda je automatické sestavení zapnuto nebo vypnuto. Přesné časování, kdy se toto sestavení objeví, nebude specifikováno. Struktura operace sestavení bude vypadat takto:

  1. Upozornění na událost PRE_BUILD (PRE_BUILD je nový název pro PRE_AUTO_BUILD)
  2. Je-li automatické sestavení zapnuto, provedení přírůstkového sestavení pracovního prostoru
  3. Upozornění na událost POST_BUILD (POST_BUILD je nový název pro POST_AUTO_BUILD)
  4. Upozornění na událost POST_CHANGE

Vztažný bod pro rozdílová data obdržená listenery automatického sestavení se bude lišit pro listenery po změně. Listener sestavení obdrží oznámení o všech změnách od konce poslední operace sestavení. Listenery po změně obdrží rozdílová data popisující všechny změny od posledního oznámení o provedené změně. Tato nová struktura si uchovává tři charakteristiky listeneru změn prostředků, které platily v platformě Eclipse od verze 1.0:

V tomto přístupu nicméně existují některé důležité rozdíly. Před Eclipse 3.0 se listenery automatického sestavení vždy volaly před listenery POST_CHANGE. Z tohoto důvodu byla rozdílová data přijatá listenery automatického sestavení vždy podmnožinou rozdílových dat, která přijaly listenery POST_CHANGE. Tento vztah se nyní v podstatě otočil. Listenery automatického sestavení přijmou rozdílová data, která jsou nadmnožinou všech rozdílových dat dodaných listenerům POST_CHANGE od dokončení posledního sestavení na pozadí. Jako dříve, listenery automatického sestavení budou moci upravovat pracovní prostor a listenery po změnách nikoliv.

Nebude nadále pravda, že po dokončení operace upravující pracovní prostor již byly upozorněny listenery AUTO_BUILD. Klientský kód, který registruje listenery změn prostředků pomocí IWorkspace.addResourceChangeListener(IResourceChangeListener) pravděpodobně nebude touto změnou ovlivněn, protože události AUTO_BUILD nebyly těmto listenerům nikdy oznamovány. Avšak klienti, kteří používají IWorkspace.addResourceChangeListener(IResourceChangeListener,int) a zadávají masku událostí obsahující události AUTO_BUILD, budou pravděpodobně touto změnou narušeni, pokud činí předpoklady o tom, kdy se listenery automatického sestavení spouští nebo ve kterém vláknu se spouští. Pokud například listener automatického sestavení aktualizuje model domény, aby odrážel změny pracovního prostoru, pak se tato aktualizace nemusela provést po návratu z operace měnící pracovní prostor. Je vhodné vzít na vědomí, že tímto způsobem může být ovlivněn pouze kód na úrovni uživatelského rozhraní. Kód na úrovni jádra, který se volá prostřednictvím rozhraní API, smí být volán v rámci rozsahu IWorkspaceRunnable, takže si nikdy nemůže být jistý, kdy se zavolají listenery změn prostředků. Doporučenou opravou tohoto narušení je použít POST_CHANGE místo listenerů sestavení, pokud je nezbytné, aby se upozornění vyskytlo před dokončením operace.

22. Upozornění po dobu operací pracovního prostoru

Nebude nadále zaručeno, že všechny změny prostředků, ke kterým dojde během dynamického rozsahu IWorkspaceRunnable, budou sloučeny do jediného upozornění. Tento mechanizmus lze stále použít pro slučování změn, aby se zabránilo zbytečnému sestavování a upozorňování, ale platforma se nyní může rozhodnout provádět upozornění během operace. Tato změna kontraktu API pravděpodobně nenaruší stávající klienty. Je ekvivalentní rozhodnutí platformy pravidelně volat IWorkspace.checkpoint během dlouho běžících operací. Důvodem této změny je, že nyní může více vláken souběžně upravovat pracovní prostor. Když jedno vlákno úpravy pracovního prostoru dokončí, je zapotřebí upozornění, aby se zabránilo problémům s odezvou, i když další operace ještě nebyla dokončena. Tato změna rovněž umožňuje uživatelům začít pracovat s množinou prostředků předtím, než se operace dokončí. Nyní uživatel například může začít procházet soubory v projektu, který je stále v procesu zapůjčení. Nová metoda IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) má volitelný příznak AVOID_UPDATE, který mohou operace použít k určení, zda jsou pravidelné aktualizace žádoucí.

23. Rozšíření popisovače toku adres URL

Co je ovlivněno: Moduly plug-in, které přispívají rozšířeními do bodu rozšíření org.eclipse.core.runtime.urlHandlers.

Popis: Kontrakt pro bod rozšíření org.eclipse.core.runtime.urlHandlers byl změněn, aby používal službu popisovače toku adres URL (URL Stream Handler), kterou poskytuje OSGi. Podpora v OSGi předčí podporu v Eclipse 2.1 a správně ošetřuje dynamické popisovače. Vzhledem k různým aspektům návrhu pomocí standardního mechanizmu popisovačů pro adresy URL v prostředí Java musí popisovače URLStreamHandler registrované u služby OSGi pro popisovače implementovat org.osgi.service.url.URLStreamHandlerService.

Nezbytná akce: Dříve musela třída popisovačů implementovat java.net.URLStreamHandler a rozšířit bod rozšíření urlHandlers. Tento bod rozšíření není nadále podporován a popisovač se musí aktualizovat tak, aby implementoval rozhraní org.osgi.service.url.URLStreamHandlerService. Struktura OSGi poskytuje abstraktní základní třídu (org.osgi.service.url.AbstractURLStreamHandlerService), od níž je možno triviálním způsobem vytvořit podtřídu, která tuto roli naplní.

Místo registrace popisovače pomocí bodu rozšíření musí nyní moduly plug-in registrovat svůj popisovač jako službu. Například

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

24. Pořadí zavádění tříd

Co je ovlivněno: Moduly plug-in, jenž dodávají poskytnuté balíčky, které rovněž dodávají jiné moduly plug-in. Tato změna ovlivňuje velmi malý počet modulů plug-in, a některé z ovlivněných dokonce k jejich prospěchu (viz níže).

Popis: V Eclipse 2.x zaváděče tříd vyhledávají třídy v následujícím pořadí: Konzultují (1) nadřazený zaváděč tříd (to je v praxi zaváděč třídy zavádění systému Java), poté (2) obsah své vlastní cesty ke třídě, a konečně (3) všechny své nezbytné předpoklady v pořadí podle deklarací. OSGi nabízí nad tímto modelem optimalizaci. Podle tohoto přístupu zaváděč tříd zkonzultuje (1) nadřazený zaváděč tříd (efektivně opět zaváděč třídy zavádění systému Java) a pak buď (2a) jediný nezbytný předpoklad, o kterém je známo, že přispívá třídami v dotazovaném balíčku, nebo (2b) položky své vlastní cesty ke třídě pro požadovanou třídu.

Zaváděč tříd určuje, zda konzultovat sám sebe nebo své nezbytné předpoklady, na základě svých importovaných a požadovaných balíčků. Tato informace je odvozena z obsahu modulu plug-in v případě tradičních modulů plug-in, nebo přímo uvedena v případě modulů plug-in s explicitním manifestem balíku OSGi. V obou případech je a priori známo, které zaváděče tříd dodají třídy pro konkrétní balíčky. To nabízí zvýšení výkonu a také řešení sužujícího problému, když několik nezbytných předpokladů přispívá stejnými třídami.

Vezměme si například případ modulů Xerces a Xalan, které oba obsahují různé třídy z balíčků org.xml. Při použití prvního přístupu by modul plug-in Xerces viděl svou kopii těchto tříd, zatímco modul plug-in Xalan by viděl také svou vlastní kopii. Jelikož tyto moduly plug-in musí komunikovat, vyskytnou se výjimky ClassCastException. Při použití druhého přístupu přispěje duplicitními třídami pouze jeden z těchto dvou modulů plug-in a oba moduly uvidí stejnou kopii.

Nezbytná akce: Nezbytná akce závisí na konkrétním případu použití. Ovlivnění vývojáři musí přezkoumat své cesty ke třídám (classpath) a vyřešit případné konflikty, ke kterým může docházet.

25. Doména ochrany zaváděče tříd není nastavena

Co je ovlivněno: Moduly plug-in, které očekávají, že doména ochrany jejich zaváděče tříd je vždy nastavena.

Popis: V Eclipse 2.1 byly zaváděče tříd modulů plug-in třídami java.security.SecureClassLoader a jako takové měly vždy nastavenu doménu ochrany. V Eclipse 3.0 zaváděče tříd nerozšiřují SecureClassloader a nastavují doménu ochrany pouze tehdy, pokud je zapnuto zabezpečení prostředí Java (což není běžný případ).

Nezbytná akce: Nezbytná akce závisí na scénáři, v němž modul plug-in používá doménu ochrany.

26. Přetypování objektů na PluginModel

Co je ovlivněno: Modely plug-in, které přetypovávají objekty typu org.eclipse.core.runtime.IPlugin* na org.eclipse.core.runtime.model.Plugin*Model. Ačkoliv vztah mezi těmito rozhraními a třídami modelu není v rozhraní API Eclipse 2.1 specifikován, ohlašujeme tuto změnu, neboť jsme nalezli instance modulů plug-in, které na tento vztah v implementaci verze 2.1 spoléhají.

Popis: Eclipse API poskytuje řadu rozhraní (např. IPluginDescriptor) a takzvané třídy "modelu" (např. PluginDescriptorModel), které se vztahují k modulům plug-in a jejich registru. V implementaci Eclipse 2.1 se stalo, že třídy modelu implementovaly odpovídající rozhraní. V nové běhové komponentě na bázi OSGi byl registr modulů plug-in značně přepracován, aby bylo umožněno oddělení aspektů načítání tříd a nezbytných předpokladů od aspektů rozšíření a bodů rozšíření. Běhová komponenta Eclipse 3.0 jako taková nemůže udržovat implementační vztah, který je přítomen ve verzi 2.1.

Nezbytná akce: Kód modulů plug-in, které spoléhají na tento vztah nespecifikovaný v rozhraní API, musí být přepracovány podle konkrétního případu použití. Další informace o tomto tématu najdete v oddílu doporučených změn v tomto dokumentu a dokumentaci Javadoc pro související třídy a metody.

27. Nekompletní implementace ILibrary

Co je ovlivněno: Moduly plug-in, které používají org.eclipse.core.runtime.ILibrary.

Popis: Nová běhová komponenta udržuje položky cesty ke třídě v jiné a nekompatibilní podobě oproti Eclipse. V důsledku toho nemůže vrstva kompatibility správně modelovat základní struktury OSGi jako objekty ILibrary. Podpora kompatibility běhové komponenty vytváří objekty ILibrary, ale musí předpokládat výchozí hodnoty pro vše kromě cesty knihovny.

Nezbytná akce: Uživatelé ILibrary by měli zvážit přístup k požadovaným hodnotám hlaviček (např. Bundle-Classpath) z příslušného balíku (viz Bundle.getHeaders()) a použití třídy pomocníka ManifestElement k interpretaci položek. Další podrobnosti viz dokumentace Javadoc ke třídě.

28. Neplatné předpoklady o formě adres URL

Co je ovlivněno: Moduly plug-in, které činí předpoklady o své struktuře instalace, o svém umístění a o rozvržení lokálního systému souborů.

Popis: Metody, jako např. IPluginDescriptor.getInstallURL(), vrací adresy URL v určité formě. Ačkoliv jejich forma není určena, různé moduly plug-in činí předpoklady na základě aktuální implementace. Například mohou očekávat, že získají adresu URL typu file:, a použít URL.getFile() a java.io.File pro manipulaci s výsledkem. Doposud to byl proveditelný, ale poněkud křehký přístup. Pokud je například modul plug-in nainstalován na webovém serveru, je možné, že bude vrácena adresa URL typu http:. Nová běhová komponenta Eclipse 3.0 je ještě tvárnější a otevírá více možností pro konfigurace provádění (např. udržování celých modulů plug-in v souborech JAR, oproti rozbalení do adresářů). To znamená, že nová běhová komponenta založená na OSGi sice nenarušuje rozhraní API verze 2.1, ale odkrývá více případů, kdy jsou předpoklady ve stávajících modulech plug-in neplatné.

Nezbytná akce: Autoři modulů plug-in by měli zajistit, že informace, ke kterým potřebují přístup, jsou dostupné prostřednictvím getResource() (a jsou v cestě ke třídě), nebo použít pro přístup k obsahu modulu plug-in příslušné rozhraní API (např. Bundle.getEntry(String)).

29. Metody BootLoader přesunuty/odstraněny

Co je ovlivněno: Kód mimo moduly plug-in, který volá jisté metody ze třídy org.eclipse.core.boot.BootLoader.

Popis: Statické metody BootLoader.startup(), shutdown() a run() byly přesunuty do org.eclipse.core.runtime.adaptor.EclipseStarter, což je součást struktury OSGi. Toto API je rozhraním mezi main() v souboru startup.jar a strukturou OSGi/běhovou komponentou Eclipse. Restrukturalizace běhové komponenty neumožnila, aby tyto metody zůstaly ve třídě BootLoader. Stará třída BootLoader se nyní nachází ve vrstvě kompatibility běhové komponenty a je nepřípustná, přesunuté metody mají vytvořeny takové stuby, aby nic nedělaly.

Neexistuje žádná náhrada staré metody BootLoader.getRunnable(), neboť běhová komponenta nemůže nadále podporovat získávání jednotlivých aplikací. Uživatelé místo toho musí označit aplikaci, která je zajímá, při spuštění platformy.

Nezbytná akce: Toto rozhraní API používá obecně jen pár lidí (nelze jej použít v rámci modulu plug-in pro platformu Eclipse). Ve vzácných případech, kdy použito je, je třeba přizpůsobit kód, aby používal odpovídající metody třídy EclipseStarter.

30. Export modulu plug-in nezahrnuje automaticky jeho soubory JAR

Co je ovlivněno: Všechny moduly plug-in.

Popis: V Eclipse 2.1 řádek bin.includes ze souboru build.properties modulu plug-in nemusel obsahovat seznam souborů JAR z deklarací knihoven modulů v souboru plugin.xml; tyto soubory JAR se přidaly gratis. V Eclipse 3.0 je seznam souborů v oddílu bin.includes souboru build.properties vyčerpávajícím seznamem a musí obsahovat všechny soubory, které vývojáři modulu plug-in chtějí do svého modulu zahrnout při sestavování nebo exportu.

Nezbytná akce: Zkontrolujte, zda řádek bin.includes v souboru build.properties obsahuje všechny soubory JAR uvedené ve vašem souboru plugin.xml.

31. Reexport rozhraní API běhové komponenty

Co je ovlivněno: Moduly plug-in, které odkrývají rozhraní API, jež obsahuje prvky ze změněného rozhraní API běhové komponenty.

Popis: Různé moduly plug-in odkrývají rozhraní API, které obsahuje prvky z rozhraní API běhové komponenty. Vzhledem ke změnám v běhové komponentě Eclipse 3.0, které zde byly nastíněny, musí klientské moduly plug-in přehodnotit použití rozhraní API běhové komponenty ve svých rozhraních API.

Nezbytná akce: Tento scénář je celkem vzácný, protože se mění jen velmi malá část rozhraní API běhové komponenty platformy Eclipse. V závislosti na scénáři mohou klienti muset změnit své rozhraní API, nebo se mohou nadále spoléhat na vrstvu kompatibility.

32. Metody třídy Platform pro analýzu modulů plug-in

Co je ovlivněno: Moduly plug-in, které používají org.eclipse.core.runtime.Platform.parsePlugins(..., Factory).

Popis: Metoda org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) byla přesunuta. Rozhraní API spojené s argumentem Factory se přesunulo z modulu plug-in org.eclipse.core.runtime až do modulu plug-in org.eclipse.core.runtime.compatibility (který závisí na modulu plug-in běhové komponenty). V důsledku toho se metoda pro analýzu rovněž přesunula.

Nezbytná akce: Uživatelé této metody by měli používat stejnou metodu ve třídě org.eclipse.core.runtime.model.PluginRegistryModel.

33. Knihovny modulů plug-in dodané fragmenty

Co je ovlivněno: Moduly plug-in, které uvádějí kód ve své cestě ke třídě, ale tento kód nedodávají (tj. soubor JAR je dodán fragmentem, například modulem plug-in org.eclipse.swt).

Popis: Nová běhová komponenta musí v zákulisí převést soubory plug.xml na soubory manifest.mf. To se dělá přímou mechanickou transformací a analýzou souborů JAR, které modul plug-in uvádí a dodává. V případě, kdy modul plug-in uvádí soubor JAR ve své cestě ke třídě, ale soubor JAR nedodává, není analýze k dispozici žádný kód a převaděč modulů plug-in nemůže generovat správný soubor manifest.mf.

Nezbytná akce: Poskytovatelé takových modulů plug-in musí buď provést takové změny, aby se příslušný soubor JAR dodával v modulu plug-in samotném, nebo ručně vytvořit/udržovat pro svůj modul plug-in soubor META-INF/MANIFEST.MF. To lze zpravidla provést získáním počátečního manifestu pomocí PDE a pak přidáním příslušné hlavičky Provide-Package.

34. Změny ve skriptech sestavení

Co je ovlivněno: Skripty (např. soubory Ant build.xml), které definují třídy ke třídě, jež obsahují soubory JAR a adresáře tříd související s běhovou komponentou.

Popis: Nová běhová komponenta obsahuje množství nových modulů plug-in a souborů JAR. Jejich zavedení bylo odůvodněno rozložením běhové komponenty do konfigurovatelných kusů. Pro většinu situací v době běhu jsou tyto změny transparentní. Pokud však máte vlastní skripty build.xml (nebo podobné), které v současné době kompilují kód proti org.eclipse.core.runtime, budete je muset aktualizovat, aby správně fungovaly. Typický skript obsahuje položku třídy ke třídě v úloze <javac>, která se odkazuje na modul plug-in org.eclipse.core.runtime následujícím způsobem:

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

Běhový modul plug-in nadále obsahuje většinu původního kódu běhové komponenty. Nicméně různé části běhové komponenty, které existují pouze z důvodů kompatibility, jsou nyní obsaženy v modulu plug-in pro kompatibilitu (org.eclispe.core.runtime.compatibility). Většina nového kódu běhové komponenty se nachází v kolekci modulů plug-in (org.eclipse.osgi.*).

Nezbytná akce: Vývojáři by měli podle potřeby přidat níže uvedené položky, aby vyloučili chyby kompilace. Ačkoliv je níže uvedena úplná sada souborů JAR, typická použití vyžadují při kompilaci pouze podmnožinu cest ke třídě. Jako obvykle je zahrnutí adresářů /bin na uvážení. Položky jsou zde uvedeny v logických seskupeních podle modulů plug-in, které je dodávají:

Kromě toho mohou být ve speciálních případech nezbytné následující soubory JAR:

Při aktualizaci takových skriptů byste měli rovněž využít příležitost a uklidit (tj. odebrat) odkazy na org.eclipse.core.boot. Tento modul plug-in je zastaralý a nadále neobsahuje žádný kód. Položky mohou být v cestě ke třídě uvedeny, ale neslouží žádnému účelu a měly by se odebrat. Uvažte odebrání:

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

35. Změny v úloze Ant sestavení PDE

Co je ovlivněno: Skripty (např. soubory Ant build.xml), které používají úlohu eclipse.buildScript.

Popis: Sestavení prostředí PDE zavedlo novou vlastnost v úloze eclipse.buildScript, která řídí generování skriptů sestavení modulů plug-in. To bylo odůvodněno zavedením nové běhové komponenty založené na OSGi.

Nezbytná akce: Chcete-li použít Eclipse 3.0 k sestavení produktu na základě 2.1, zaveďte do eclipse.buildScript vlastnost "buildingOSGi" a nastavte ji na hodnotu false. Například:

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

36. Změny v úloze Ant eclipse.build

Co je ovlivněno: Skripty (např. soubory Ant build.xml), které používají úlohu eclipse.buildScript.

Popis: Sestavení prostředí PDE zavedlo novou vlastnost v úloze eclipse.buildScript, která řídí generování skriptů sestavení modulů plug-in. To bylo odůvodněno zavedením nové běhové komponenty založené na OSGi.

Nezbytná akce: Chcete-li použít Eclipse 3.0 k sestavení produktu na základě 2.1, zaveďte do eclipse.buildScript vlastnost "buildingOSGi" a nastavte ji na hodnotu false. Například:

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

37. Změny v úloze Ant eclipse.fetch

Co je ovlivněno: Skripty (např. soubory Ant build.xml), které používají úlohu eclipse.buildScript.

Popis: Sestavení prostředí PDE změnilo chování úlohy eclipse.fetch, aby se usnadnilo sestavování platformy Eclipse automatizovaným stylem sestavení. Styl elements nyní podporuje najednou pouze jednu položku a scriptName se vždy ignoruje.

Nezbytná akce: Pokud jste ve značce "elements" volání eclipse.fetch měli seznam položek, rozdělte je mezi několik volání eclipse.fetch. Pokud jste nastavovali scriptName, vezměte na vědomí, že generovaný skript načtení se nyní vždy nazývá "fetch_{elementId}". Například:

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

se změní na

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

38. Náhrada souboru install.ini

Soubor install.ini není nadále obsažen. Na jeho místě je nyní nový soubor config.ini v konfiguračním podadresáři. Produkty, které používaly soubor install.ini k určení primární funkce (např. k poskytnutí informací o značení), musí místo toho změnit soubor config.ini. Kromě nového názvu souboru se také změnily názvy klíčů.

Hodnota klíče feature.default.id z verze 2.1 by se měla nastavit jako hodnota nového klíče eclipse.product. Hodnota eclipse.application by se měla nastavit na "org.eclipse.ui.ide.workbench".

Konečně, ve verzi 2.1 byl úvodním obrázkem vždy soubor splash.bmp v adresáři modulu plug-in značení. Ve verzi 3.0 je umístění úvodního obrázku explicitně dáno klíčem osgi.splashPath v souboru config.ini.