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.
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.
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 |
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.
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.
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í:
org.eclipse.core.runtime.jobs.ILock
.
Výhodou zámků ILock
oproti obecným zámkům je automatické přepínání na vlákno uživatelského rozhraní při provádění syncExec
a podpora detekce zablokování vestavěná do jejich implementace, která zablokování zaprotokoluje a pak vyřeší.Display.asyncExec
),
která se celá zpracovává ve vláknu uživatelského rozhraní.java.lang.String
a org.eclipse.core.runtime.IPath
, neporušovaly vlákna. Výhodou neměnných objektů je velmi rychlý přístup pro čtení za cenu práce navíc při změně.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.)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.
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.
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
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.
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.
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ě.
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.
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.
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:
Změny v org.eclipse.ui.texteditor.AbstractTextEditor:
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
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:
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
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.
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.
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í.
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.
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í.
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í.
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.
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:
PRE_DELETE
nebo PRE_CLOSE
PRE_AUTO_BUILD
POST_AUTO_BUILD
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:
PRE_DELETE
nebo PRE_CLOSE
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:
PRE_BUILD
(PRE_BUILD
je nový
název pro PRE_AUTO_BUILD)
POST_BUILD
(POST_BUILD
je nový
název pro POST_AUTO_BUILD)
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:
POST_CHANGE
(po změně) přijímají upozornění na absolutně všechny změny prostředků, které se vyskytnou během doby, po kterou jsou registrovány. To zahrnuje změny provedené tvůrci i změny provedené jinými listenery.PRE_AUTO_BUILD
přijímají upozornění na všechny změny prostředků, kromě změn, které provedli tvůrci a listenery změn prostředků.
POST_AUTO_BUILD
přijímají upozornění na všechny změny prostředků, kromě změn, které provedly jiné listenery POST_AUTO_BUILD
.
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.
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í.
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);
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.
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.
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.
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ě.
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)
).
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.
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.
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.
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
.
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.
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
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"/>
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"/>
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" .../>
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.