W wersji 3.0 środowiska Eclipse wprowadzono zmiany powodujące niezgodność z wersją 2.1, które mają wpływ na wtyczki. Poniżej opisano obszary, w których nastąpiły zmiany, a także podano instrukcje umożliwiające migrację wtyczek z wersji 2.1 do wersji 3.0. Z podanych informacji należy korzystać jedynie w sytuacji, gdy przy uruchamianiu wtyczki z wersji 2.1 w środowisku w wersji 3.0 występują problemy.
Nagłówek plików manifestu dla wtyczek (i fragmentów wtyczek) uległ zmianie polegającej na dodaniu nowego wiersza, który identyfikuje wersję manifestu odpowiedniej wtyczki. Przed wprowadzeniem wersji 3.0 wtyczki nie zawierały wierszy <?eclipse ...?>; począwszy od wersji 3.0 obecność takiego wiersza jest obowiązkowa. Zmiana ma na celu umożliwienie bezbłędnego rozpoznania przez środowisko wykonawcze Eclipse wtyczek z wersji wcześniejszych niż 3.0, które nie zostały przeniesione do wersji 3.0 - dzięki temu możliwe jest automatycznie udostępnienie większego stopnia kompatybilności binarnej na potrzeby tego rodzaju wtyczek. Ogólna forma pliku plugin.xml wygląda następująco (plik fragment.xml jest podobny):
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
...
</plugin>
Manifesty wtyczek utworzone w środowisku PDE 3.0 przyjmują taką formę automatycznie. Zaleca się stanowczo użycie narzędzia do migrowania wtyczek dostępnego w środowisku PDE. Pozwala ono wstawiać automatycznie wskazane wiersze do manifestu wtyczek i ich fragmentów z wersji 2.1, a także rozwiązać problemy wynikające z innych opisanych tutaj zmian.
Po dodaniu tej dyrektywy do pliku plugin.xml (ręcznie lub przy użyciu narzędzia PDE) należy jeszcze zaktualizować plik, tak aby jawnie uwzględniał listę wtyczek, od których jest zależny. Przykładowo przed wprowadzeniem środowiska Eclipse w wersji 3.0 zależności od wtyczki org.eclipse.core.runtime i org.eclipse.core.boot miały charakter niejawny. Wraz z wprowadzeniem wersji 3.0 wtyczka org.eclipse.core.boot nie jest już potrzebna i programiści powinni korzystać odpowiednio z wtyczki org.eclipse.core.runtime lub org.eclipse.core.runtime.compatibility (albo nie używać żadnej z nich).
Uwaga: Jest to jedna z niekompatybilności, które nie mają wpływu na sposób uruchamiania binarnych wtyczek z wersji 2.1 w środowisku Eclipse 3.0.
Wtyczka org.eclipse.ui, która do tej pory stanowiła główną wtyczkę interfejsu użytkownika platformy, teraz udostępnia jedynie interfejs API oraz punkty rozszerzeń dla ogólnego (tj. niezwiązanego z żadnym konkretnym środowiskiem IDE) środowiska roboczego. Interfejsy API i punkty rozszerzeń o charakterze opcjonalnym lub związanym z określonym środowiskiem IDE zostały przeniesione do innych wtyczek.
Ma to konsekwencje dwojakiego rodzaju: (1) przeniesione punkty rozszerzeń wtyczki org.eclipse.ui mają nowe identyfikatory; (2) lista wymaganych wtyczek uległa zmianie.
Punkty rozszerzeń z wtyczki org.eclipse.ui w przedstawionej poniżej tabeli zostały przeniesione do innych wtyczek, co pociągnęło za sobą zmianę ich identyfikatorów. Jeśli istniejąca wtyczka wnosi rozszerzenie do przeniesionych punktów rozszerzeń, należy zmodyfikować odwołanie w atrybucie "point" przy elemencie <extension> w pliku manifestu wtyczki, tak aby wskazywało na nowy identyfikator danego punktu rozszerzenia. Odpowiednią poprawkę można wprowadzić za pomocą narzędzia do migrowania wtyczek wchodzącego w skład środowiska PDE.
Uwaga: Jest to jedna z niekompatybilności, które nie mają wpływu na sposób uruchamiania binarnych wtyczek z wersji 2.1 w środowisku Eclipse 3.0. Środowisko wykonawcze Eclipse 3.0 automatycznie wykrywa wtyczki z wersji wcześniejszych niż 3.0 (na podstawie nieobecności wspomnianego wcześniej wiersza <?eclipse version="3.0"?> w manifeście wtyczki) i uwzględnia opisane zmiany w zakresie zależności punktów rozszerzeń i wtyczek.
Stary identyfikator punktu rozszerzenia |
Nowy identyfikator punktu rozszerzenia |
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 |
W kolejnej tabeli wymieniono pakiety API udostępniane wcześniej przez wtyczkę org.eclipse.ui, które zostały przeniesione do innych wtyczek (nazwy pakietów API, klas, pól i metod nie uległy zmianie). W niektórych przypadkach pakiety API zostały podzielone między kilka wtyczek. Ponieważ klasy API widoczne dla danej wtyczki zależą od zdefiniowanej w nim listy wymaganych wtyczek, zmiany te mogą wymagać dostosowania elementów "<requires>" w manifeście istniejącej wtyczki w celu ponownego uzyskania dostępu do klasy API.
Ta zmiana dotyczy jedynie wtyczek zależnych od wtyczki org.eclipse.ui (tzn. zawierających wpis <import plugin="org.eclipse.ui"/> w sekcji <requires> manifestu wtyczki) - zmiana nie ma natomiast wpływu na żadne inne wtyczki. Jeśli wtyczka należy do pierwszej z wymienionych grup, być może konieczne będzie zmodyfikowanie elementu <import> lub wstawienie dodatkowych elementów <import>, tak aby wszystkie wymagane klasy API znalazły się w zasięgu. Zaleca się stanowczo, aby wtyczki deklarowały zależności wyłącznie od wtyczek, które są faktycznie wykorzystywane. Uwzględnienie niepotrzebnych zależności wpływa negatywnie na wydajność środowiska wykonawczego, ponieważ program ładujący klasy Java musi wyszukiwać klasy we wszystkich zależnych jednostkach kompilacji (narzędzie do migrowania wtyczek wchodzące w skład środowiska PDE pozwala wprowadzić odpowiednie poprawki w zakresie zależności i określić niezbędny zestaw).
Pakiet API |
Wtyczka w wersji 2.1 |
Odpowiadająca mu wtyczka (lub wtyczki) w wersji 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 |
Środowisko wykonawcze platformy Eclipse 3.0 bazuje na specyfikacji OSGi, co wiąże się ze zmianami w zakresie struktury dwóch wtyczek tego środowiska: org.eclipse.core.runtime oraz org.eclipse.core.boot.
Nowa wtyczka org.eclipse.core.runtime.compatibility udostępnia pomost implementacyjny między starymi i nowymi interfejsami API i pełni rolę magazynu dla wielu przestarzałych interfejsów API znajdujących się wcześniej we wtyczkach org.eclipse.core.runtime oraz org.eclipse.core.boot. Restrukturyzacja nie wpływa na punkty rozszerzeń środowiska wykonawczego platformy.
Podczas migrowania istniejącej wtyczki do wersji 3.0 jej manifest wymaga aktualizacji w celu uwzględnienia nowej struktury wtyczek środowiska wykonawczego platformy Eclipse. Jeśli zachodzi taka konieczność, odpowiednią zależność można dodać do wtyczki org.eclipse.core.runtime.compatibility za pomocą narzędzia do migrowania manifestów wtyczek wchodzącego w skład środowiska PDE.
Należy również zauważyć, że oznaczenie wtyczki jako wtyczki 3.0 (za pomocą wpisu <?eclipse version="3.0"?>) w przypadku wtyczki, która definiuje klasę Plugin, pociąga za sobą konieczność jawnego uwzględnienia instrukcji <import plugin="org.eclipse.core.runtime.compatibility"/> w manifeście wtyczki albo zapewnienia, że klasa Plugin definiuje konstruktor domyślny.
Uwaga: Jest to jedna z niekompatybilności, które nie mają wpływu na sposób uruchamiania binarnych wtyczek z wersji 2.1 w środowisku Eclipse 3.0. Środowisko wykonawcze Eclipse 3.0 automatycznie wykrywa wtyczki z wersji wcześniejszych niż 3.0 (na podstawie nieobecności wiersza <?eclipse version="3.0"?> w manifeście wtyczki) i uwzględnia opisane wyżej zmiany.
Wtyczka org.eclipse.xerces nie jest już potrzebna i została usunięta. Obsługa analizy składni XML jest wbudowana w narzędzie J2SE 1.4, a obecność wtyczki Xerces powoduje konflikty programów ładujących klasy. Pakiety API javax.xml.parsers, org.w3c.dom.* oraz org.xml.sax.*, udostępniane wcześniej przez wtyczkę org.eclipse.xerces, są teraz dostępne z poziomu bibliotek J2SE.
Jeśli dana wtyczka wymaga wtyczki org.eclipse.xerces, należy zmodyfikować jej manifest w celu usunięcia zadeklarowanej zależności. Po wykonaniu tej czynności kod wtyczki powinien kompilować się i uruchamiać bez konieczności dalszych zmian.
W przypadku próby uruchomienia w standardowej konfiguracji środowiska Eclipse 3.0 binarnych wtyczek z wersji 2.1 z zadeklarowaną zależnością od wtyczki org.eclipse.xerces wystąpi błąd niespełnienia wymagań wstępnych. Wskutek tego dana wtyczka nie zostanie aktywowana.
Przed wprowadzeniem wersji 3.0 środowisko Eclipse operowało w przeważającej części w ramach pojedynczego wątku. Większość punktów rozszerzeń i metod API operowała w wątku interfejsu użytkownika lub w wątku utworzonym przez okno dialogowe postępu blokujące wątek interfejsu użytkownika. Autorzy wtyczek nie musieli przeważnie martwić się o bezpieczeństwo wątku poza zapewnieniem, że cała aktywność związana z interfejsem użytkownika odbywa się w ramach wątku tego interfejsu. Środowisko Eclipse 3.0 charakteryzuje się dużo większym stopniem współbieżności. Wiele operacji odbywa się obecnie w tle, gdzie mogą one być wykonywane współbieżnie z innymi wątkami, w tym z wątkiem interfejsu użytkownika. Wszystkie wtyczki, których kod wykonywany jest w wątku tła, muszą uwzględniać względy bezpieczeństwa.
Oprócz wtyczek jawnie wykonujących operacje w tle przy użyciu
interfejsu API org.eclipse.core.runtime.jobs
dostępnych jest kilka
punktów rozszerzeń i funkcji API korzystających z wątków tła. Wtyczki posiłkujące się tymi udogodnieniami muszą gwarantować, że ich kod
jest wątkowo bezpieczny. W tabeli poniżej przedstawiono podsumowanie
interfejsów API i punktów rozszerzeń, których kod jest wykonywany w środowisku
Eclipse 3.0 w całości lub w części w ramach wątku tła:
Punkt rozszerzenia lub klasa API |
Uwagi |
org.eclipse.core.runtime.IRegistryChangeListener | Nowy element w środowisku Eclipse 3.0, wykonywany w tle. |
org.eclipse.core.resources.IResourceChangeListener | Zdarzenia AUTO_BUILD są obecnie wykonywane w tle. |
org.eclipse.core.resources.builders (punkt rozszerzenia) | Automatyczne budowanie odbywa się teraz w tle. |
org.eclipse.core.resources.ISaveParticipant | Element SNAPSHOT działa teraz w tle. |
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (punkt rozszerzenia) | Nowy element w środowisku Eclipse 3.0, wykonywany w tle. |
org.eclipse.ui.decorators (punkt rozszerzenia) | Element wykonywany w tle już w wersji Eclipse 2.1. |
org.eclipse.ui.startup (punkt rozszerzenia) | Element wykonywany w tle już w wersji Eclipse 2.1. |
org.eclipse.team.core.org.eclipse.team.core.repository (punkt rozszerzenia) | Wiele operacji jest teraz wykonywanych w tle. |
org.eclipse.team.ui.synchronizeParticipants (punkt rozszerzenia) | Nowy element w środowisku Eclipse 3.0, wykonywany w tle. |
org.eclipse.debug.core.launchConfigurationTypes (punkt rozszerzenia) | Teraz wykonywany w tle. |
org.eclipse.jdt.core.IElementChangedListener | Element ElementChangedEvent.PRE_AUTO_BUILD jest obecnie
wykonywany w tle, element POST_RECONCILE był wykonywany w tle już
w poprzedniej wersji. |
Istnieją różne strategie umożliwiające nadanie kodowi charakteru wątkowo
bezpiecznego. Najprostsze rozwiązanie polega na tym, że wszystkie działania
odbywają się w wątku interfejsu użytkownika, co zapewnia wykonywanie w postaci
szeregowej. Jest to podejście stosowane często w przypadku takich wtyczek interfejsu użytkownika, które nie wymagają przetwarzania znacząco
obciążającego procesor. Decydując się na to podejście, należy zdawać sobie
sprawę z ryzyka zakleszczenia związanego nieodłącznie z metodą
Display.syncExec
. Metoda Display.asyncExec
jest
zwykle bezpieczniejsza, ponieważ nie powoduje ryzyka zakleszczenia, ale kosztem
utraty precyzyjnej kontroli nad tym, kiedy kod zostanie wykonany.
Inne techniki umożliwiające zagwarantowanie, że kod będzie wątkowo bezpieczny, to:
org.eclipse.core.runtime.jobs.ILock
. Przewaga obiektu
ILock
nad ogólnymi blokadami polega na możliwości automatycznego
przekazywania danych do wątku interfejsu użytkownika podczas wykonywania metody
syncExec
. Ponadto w ich implementację wbudowana jest obsługa
wykrywania zakleszczeń, która pozwala je rejestrować i rozwiązywać.Display.asyncExec
),
przetwarzania w całości w wątku interfejsu użytkownika.java.lang.String
czy
org.eclipse.core.runtime.IPath
. Zaletą obiektów niezmienialnych
jest niezwykle szybki czas dostępu przy odczycie kosztem dodatkowych nakładów
pracy związanych z modyfikacjami.Z interfejsu org.eclipse.ui.IWorkbenchPage usunięto następujące metody. Interfejs IWorkbenchPage jest deklarowany w ogólnym środowisku roboczym, ale metody są zasadniczo specyficzne dla zasobów.
Klienci tych metod IWorkbenchPage.openEditor powinni zamiast nich wywoływać odpowiadające im metody public static zadeklarowane w klasie org.eclipse.ui.ide.IDE (we wtyczce org.eclipse.ui.ide).
Klienci metod IWorkbenchPage.openSystemEditor(IFile) powinni przekształcić interfejs IFile w interfejs IEditorInput przy użyciu nowego interfejsu FileEditorInput(IFile), a następnie wywołać metodę openEditor(IEditorInput,String). Innymi słowy, należy przebudować metodę page.openSystemEditor(file) na page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Uwaga: Klienci korzystający z identyfikatora edytora IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID muszą przekazać dane wejściowe edytora implementujące interfejs org.eclipse.ui.IPathEditorInput (warunek ten spełnia FileEditorInput).
Uwaga: Jest to jedna z niekompatybilności, które nie mają wpływu na sposób uruchamiania binarnych wtyczek z wersji 2.1 w środowisku Eclipse 3.0. Platforma Eclipse 3.0 zawiera mechanizm kompatybilności binarnej środowiska wykonawczego, który zapewnia, że istniejące elementy binarne wtyczek z wersji 2.1, w których wykorzystuje się dowolne z usuniętych metod openEditor i openSystemEditor, będą nadal działały w nowej wersji pomimo zmienionego interfejsu API (usunięte metody są więc de facto "przywracane" przez fragment org.eclipse.ui.workbench.compatibility).Następująca metoda została usunięta z interfejsu org.eclipse.ui.IEditorPart. Interfejs IEditorPart jest deklarowany w ogólnym środowisku roboczym, ale metoda jest zasadniczo specyficzna dla zasobu.
Klienci wywołujący tę metodę powinni zamiast tego sprawdzić, czy interfejs edytora implementuje lub adaptuje interfejs org.eclipse.ui.ide.IGotoMarker (we wtyczce org.eclipse.ui.ide) - jeśli tak, należy wywołać metodę gotoMarker(IMarker). Klasa IDE oferuje w tym celu wygodną metodę: IDE.gotoMarker(editor, marker);
Klienci implementujący edytor, który można automatycznie ustawić na podstawie informacji IMarker, powinni zaimplementować lub zaadaptować interfejs org.eclipse.ui.ide.IGotoMarker.Ponieważ interfejs IGotoMarker ma tylko jedną metodę - gotoMarker(IMarker) - i ma tę samą sygnaturę i specyfikację co stara metoda IEditorPart.gotoMarker(IMarker), istniejące implementacje edytora można adaptować pod kątem opisywanej zmiany przez włączenie interfejsu IGotoMarker w klauzuli implements w definicji klasy.
W przypadku próby uruchomienia w standardowej konfiguracji środowiska Eclipse 3.0 binarnych wtyczek z wersji 2.1 z kodem wywołującym tę metodę wystąpi wyjątek związany z błędem łączenia klasy.
Interfejs uruchamiający edytor org.eclipse.ui.IEditorLauncher jest implementowany przez wtyczki udostępniające edytory zewnętrzne. Z interfejsu tego została usunięta przedstawiona dalej metoda. Interfejs IEditorLauncher jest deklarowany w ogólnym środowisku roboczym, ale metoda jest zasadniczo specyficzna dla danego zasobu.
Metoda ta została zastąpiona przez metodę:
W przypadku próby uruchomienia w standardowej konfiguracji środowiska Eclipse 3.0 binarnych wtyczek z wersji 2.1 z kodem wywołującym tę metodę wystąpi wyjątek związany z błędem łączenia klasy.
Z interfejsu org.eclipse.ui.IEditorRegistry usunięto następujące metody. Interfejs IEditorRegistry jest deklarowany w ogólnym środowisku roboczym, ale metody są zasadniczo specyficzne dla zasobów.
Dostępne są nowe stałe reprezentujące identyfikatory zewnętrznego edytora systemowego oraz edytora wbudowanego (SYSTEM_EXTERNAL_EDITOR_ID oraz SYSTEM_INPLACE_EDITOR_ID). Te dwa edytory wymagają danych wejściowych edytora, które implementują lub adaptują interfejs org.eclipse.ui.IPathEditorInput. Należy zauważyć, że deskryptor edytora wbudowanego nie jest dostępny w konfiguracjach środowiska Eclipse, które nie obsługują edycji wewnętrznej.
Następująca metoda została usunięta z interfejsu org.eclipse.ui.IWorkbench. Interfejs IWorkbench jest deklarowany w ogólnym środowisku roboczym, ale metoda jest zasadniczo specyficzna dla danego zasobu.
Próba uruchomienia w standardowej konfiguracji środowiska Eclipse 3.0 binarnych wtyczek z wersji 2.1 z kodem wywołującym tę metodę spowoduje wystąpienie wyjątku.
Aby uniezależnić klasę org.eclipse.ui.texteditor.AbstractTextEditor od interfejsu IFile, klasa org.eclipse.ui.texteditor.AbstractDocumentProvider wprowadza pojęcie operacji dostawcy dokumentów (DocumentProviderOperation) i programu uruchamiającego dostawcę dokumentów (IRunnableContext). Po zgłoszeniu żądania wykonania operacji resetowania, zapisu lub synchronizacji klasa AbstractDocumentProvider powoduje utworzenie odpowiednich operacji dostawcy dokumentów i korzysta z programu uruchamiającego w celu ich przeprowadzenia. Uruchamialny kontekst może być udostępniony przez podklasy za pośrednictwem metody getOperationRunner. Poniżej przedstawiono zmiany, do których klienci powinni się dostosować:
Podklasa org.eclipse.ui.editors.text.StorageDocumentProvider klasy AbstractDocumentProvider implementuje metodę getOperationRunner w taki sposób, że zawsze zwraca wartość null. Oznacza to, że omawiana zmiana nie powinna mieć wpływu na podklasy klasy StorageDocumentProvider.
Podklasa org.eclipse.ui.editors.text.FileDocumentProvider klasy StorageDocumentProvider implementuje metodę getOperationRunner, która zwraca interfejs IRunnableContext w celu wykonania operacji DocumentProviderOperations w ramach WorkspaceModifyOperation. Inne zmiany w zakresie podklasy FileDocumentProvider są następujące:
Zmiany w zakresie klasy 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);
Podklasa org.eclipse.ui.texteditor.StatusTextEditor klasy AbstractTextEditor udostępnia metodę predykatu isErrorStatus(IStatus). W podklasach może być stosowane przesłanianie w celu określenia, czy dany stan ma być uznany za błąd, czy też nie.
Zmiany w zakresie klasy org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:
W ramach wprowadzenia obsługi adnotacji bez nagłówka dokonano następujących zmian w klasie 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
Środowisko Eclipse 3.0 udostępnia teraz ogólną obsługę konsoli. Dostęp do ogólnej konsoli można uzyskać za pomocą opcji Okna > Pokaż widok > Podstawowe > Konsola. Korzysta się z niej w ramach debugowania w środowisku Eclipse oraz integracji narzędzia Ant.
Identyfikator widoku konsoli został zmieniony z org.eclipse.debug.ui.ConsoleView na org.eclipse.ui.console.ConsoleView. Działanie wtyczek z wersji 2.1, które programowo otwierają konsolę, nie powiedzie się, ponieważ stary widok już nie istnieje.
W wersji 3.0 typy zwracanych wartości dla metod org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) oraz installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) zostały zmienione z boolean na int, tak aby funkcję nasłuchujące mogły zgłaszać sygnał "nieistotne". W wydaniach poprzedzających wersję 3.0 funkcje nasłuchiwania mogły jedynie zgłaszać sygnały "zawieś" lub "nie zawieszaj" w razie natrafienia na punkt zatrzymania albo "instaluj" lub "nie instaluj", gdy punkt zatrzymania miał zostać zainstalowany. W wersji 3.0 funkcje nasłuchiwania mogą również zgłaszać sygnał "nieistotne" dla każdej z powyższych okoliczności. Pozwala to klientom podejmować konkretną decyzję tylko w tych sytuacjach, w których ma ona dla nich istotne znaczenie. W przypadku powiadomień typu "napotkano punkt zatrzymania" punkt zatrzymania spowoduje zawieszenie, jeśli którakolwiek z funkcji nasłuchiwania zgłosi sygnał "zawieś" lub wszystkie funkcje nasłuchiwania zgłoszą sygnał "nieistotne"; punkt zatrzymania nie spowoduje zawieszenia, jeśli przynajmniej jedna klasa nasłuchiwania zgłosi sygnał "nie zawieszaj" i żadna klasa nie zagłosuje "zawieś". W przypadku powiadomień typu "instalowanie punktu zatrzymania" punkt zatrzymania zostanie zainstalowany, jeśli którakolwiek z funkcji nasłuchiwania zagłosuje za jego zainstalowaniem lub wszystkie funkcje nasłuchiwania zgłoszą sygnał "nieistotne"; punkt zatrzymania nie zostanie zainstalowany, jeśli przynajmniej jedna funkcja nasłuchiwania zgłosi sygnał "nie instaluj" i żadna funkcja nie zagłosuje "instaluj". Ogólnie implementatorzy powinni zwracać wartość DONT_CARE (nieistotne), chyba że istnieje wyraźna przesłanka przemawiająca za wyborem konkretnej opcji. Ważne aby pamiętać, że np. zagłosowanie "zawieś" spowoduje przesłonięcie sygnału "nie zawieszaj" zgłoszonego przez dowolną z pozostałych funkcji nasłuchiwania.
Interfejs IJavaBreakpointListener jest implementowany przez klientów, którzy tworzą punkty zatrzymania w kodzie Java albo reagują na nie. Prawdopodobnie istnieje niewielu takich klientów oprócz samego zestawu narzędzi JDT oraz klienta, który zgłosił problem (defekt 37760) będący przyczyną opracowania opisywanej zmiany. Zmiana ta ma istotne znaczenie z punktu widzenia istniejącego kodu, który implementuje interfejs IJavaBreakpointListener. Taki kod wymaga modyfikacji, aby zwracał odpowiednią wartość int, zanim będzie możliwe jego skompilowanie lub uruchomienie w wersji 3.0.
Przed wprowadzeniem wersji 3.0 metody w klasie SWT org.eclipse.swt.dnd.Clipboard mogły być domyślnie uruchamiane w wątkach innych niż wątek interfejsu użytkownika. To przeoczenie powodowało awarie w zestawie GTK, gdzie system operacyjny wymaga, aby wszystkie interakcje schowka odbywały się w obrębie wątku interfejsu użytkownika. Nie zostało ono wcześniej wykryte, ponieważ wiele aplikacji ma charakter jednowątkowy, a większość przeprowadzanych na nich testów odbywa się w systemie Windows. Aby interfejs API schowka działał prawidłowo i miał charakter wieloplatformowy, w wersji 3.0 zmieniono specyfikację i implementację wszystkich metod tego interfejsu w taki sposób, aby zgłaszały wyjątek SWT (ERROR_THREAD_INVALID_ACCESS) w razie wywołania z wątku innego niż wątek interfejsu użytkownika. Usługi schowka są często udostępniane automatycznie przez komponenty środowiska Eclipse takie jak edytor tekstu, co izoluje wielu klientów od tej istotnej zmiany. Istniejący kod, który bezpośrednio odwołuje się do schowka, powinien gwarantować, że metody API są wywoływane w ramach odpowiedniego wątku - w razie potrzeby należy użyć metody Display.asyncExec lub syncExecwhen, aby przełączyć dostęp do wątku interfejsu użytkownika.
W wersji 3.0 zestaw SWT zgłasza zdarzenia naciśnięcia klawiszy przed uruchomieniem odpowiedniego procesu w systemie operacyjnym. Zdarzenia te są zatem zgłaszanie dużo wcześniej, niż miało to miejsce we wcześniejszych wersjach. Odpowiednia zmiana została wprowadzona w celu umożliwienia przypisań klawiszy w środowisku Eclipse, co rodzi konieczność przechwytywania zdarzeń klawiszy, zanim jakikolwiek widget uzyska możliwość przetworzenia danego znaku. Konsekwencje tej zmiany są widoczne w kodzie, który bezpośrednio obsługuje zdarzenia niskopoziomowe org.eclipse.swt.SWT.KeyDown. Oznacza to na przykład, że gdy funkcja nasłuchiwania widgetu Text odbierze zdarzenie naciśnięcia klawisza, treść widgetu (getText()) nie będzie jeszcze obejmowała naciśniętego klawisza (w przeciwieństwie do wersji wcześniejszych niż 3.0). Zalecanym sposobem uzyskania pełnego tekstu z widgetu wraz z bieżącym klawiszem jest użycie zdarzeń wyższego poziomu SWT.Modify lub SWT.Verify zamiast zdarzenia niskiego poziomu SWT.KeyDown. Opisana tutaj zmiana nie ma żadnego wpływu na kod, w którym stosowano już wcześniej takie podejście.
W wersjach poprzedzających wersję 3.0 naciśnięcie kombinacji klawiszy Ctrl+Tab, Shift+Tab, Ctrl+PgUp lub Ctrl+PgDn przy aktywnej klasie SWT org.eclipse.swt.widgets.Canvas lub jednej z jej podklas (łącznie z widgetami niestandardowymi) powodowało automatyczne przejście do następnego/poprzedniego widgetu bez zgłaszania zdarzenia klawisza. Zachowanie to nie wynikało ze specyfikacji i jest niezgodne z zasadą, że klasy Canvas widzą każdy klawisz wpisany w ich obrębie. Prawidłowy sposób obsługi przechodzenia po elementach polega na zarejestrowaniu odpowiedniej funkcji nasłuchującej. Aby zapewnić właściwą obsługę przypisań klawiszy w środowisku Eclipse 3.0, zmieniono domyślne zachowanie, tak że zamiast przechodzenia klasa Canvas widzi teraz zdarzenia klawiszy Ctrl+Tab, Shift+Tab, Ctrl+PgUp oraz Ctrl+PgDn. Jeśli korzysta się bezpośrednio z klasy Canvas lub definiuje jej podklasę, trzeba się upewnić, że zarejestrowano funkcję nasłuchiwania przechodzenia.
Wybór elementów w klasach SWT org.eclipse.swt.widgets.Table oraz Tree za pomocą myszy powoduje we wszystkich środowiskach operacyjnych wygenerowanie jednakowej sekwencji: naciśnięcie przycisku myszy-wybór-zwolnienie przycisku myszy. Podobnie wybór elementów za pomocą klawiatury powoduje we wszystkich środowiskach operacyjnych wygenerowanie takiej samej sekwencji zdarzeń: naciśnięcie klawisza-wybór-zwolnienie klawisza. W wersjach wcześniejszych niż wersja 3.0 porządek zdarzeń nie był jednakowy - środowiska Motif oraz Photon odbiegały tutaj od pozostałych, zawsze w pierwszej kolejności zgłaszając zdarzenie wyboru, tzn. wybór-naciśnięcie przycisku myszy-zwolnienie przycisku myszy lub wybór-naciśnięcie klawisza-zwolnienie klawisza. W wersji 3.0 kolejność zdarzeń w środowiskach Motif i Photon została dopasowana do pozostałych środowisk. Istniejący kod, który działał prawidłowo w środowiskach Windows, GTK, Motif i Photon, najprawdopodobniej nie będzie wymagać żadnych zmian. Zaleca się jednak sprawdzenie kodu i upewnienie się, że nie polega na niepoprawnej kolejności zdarzeń.
Interfejs org.eclipse.core.runtime.IStatus
ma nową stałą
istotności, IStatus.CANCEL
, która może posłużyć do wskazania
anulowania. Dodatek ten wpływa na metody wywołujące metodę
IStatus.getSeverity()
, które polegają na zestawie możliwych
statusów istotności ograniczonym do stałych IStatus.OK
,
INFO
, WARNING
oraz ERROR
. Należy
zaktualizować kod metod wywołujących metodę getSeverity
w celu
uwzględnienia nowego poziomu istotności.
W środowisku Eclipse 3.0 automatyczne budowanie obszaru roboczego odbywa się
w wątku tła. Wymagało to zmiany kontraktu API na
org.eclipse.core.resources.IResourceChangeEvent
. Kontrakt
interfejsu IResourceChangeEvent
gwarantował wcześniej następujący
porządek zdarzeń w przypadku wszystkich zmian obszaru roboczego:
PRE_DELETE
lub
PRE_CLOSE
(jeśli ma zastosowanie).PRE_AUTO_BUILD
.POST_AUTO_BUILD
.POST_CHANGE
.Ponieważ automatyczne budowanie odbywa się teraz w tle, nie ma gwarancji
dotyczących czasowego związku między zdarzeniami AUTO_BUILD
i
zdarzeniem POST_CHANGE
. W środowisku 3.0 kroki 3-5 w powyższej
strukturze zostały usuniętej z operacji. Efekt przedstawia się następująco:
PRE_DELETE
lub
PRE_CLOSE
(jeśli ma zastosowanie).POST_CHANGE
.Operacja budowania obszaru roboczego w tle jest wykonywana okresowo przez platformę. Należy zauważyć, że ma to miejsce niezależnie od tego, czy automatyczne budowanie jest włączone, czy wyłączone. Nie jest możliwe podanie dokładnych ram czasowych, w jakich zostanie przeprowadzone budowanie. Struktura przykładowej operacji budowania może wyglądać następująco:
PRE_BUILD
(PRE_BUILD
to nowa nazwa dla PRE_AUTO_BUILD)
.POST_BUILD
(POST_BUILD
to nowa nazwa dla POST_AUTO_BUILD)
.POST_CHANGE
.Punkt odwołania dla wartości delta odebranych przez funkcje nasłuchiwania automatycznego budowania będzie inny niż w przypadku nasłuchiwania zdarzeń post-change. Funkcje nasłuchiwania budowania będą odbierać powiadomienia o wszystkich zmianach od momentu zakończenia ostatniej operacji budowania. Funkcje nasłuchiwania zdarzeń post-change będą odbierać wartości delta opisujące wszystkie zmiany od ostatniego powiadomienia o wprowadzonych zmianach. Ta nowa struktura zachowuje trzy cechy charakterystyczne funkcji nasłuchiwania zmian zasobów aktualne od czasu pojawienia się środowiska Eclipse w wersji 1.0:
POST_CHANGE
odbierają powiadomienia o
absolutnie wszystkich zmianach zasobów, które zachodzą w czasie, gdy są one
zarejestrowane. Obejmuje to zmiany wprowadzane przez programy budujące oraz
przez inne funkcje nasłuchiwania.PRE_AUTO_BUILD
odbierają powiadomienia o
wszystkich zmianach zasobów z wyjątkiem zmian wprowadzanych przez
programy budujące oraz funkcje nasłuchiwania zmian zasobów.
POST_AUTO_BUILD
odbierają powiadomienia
o wszystkich zmianach zasobów z wyjątkiem zmian wprowadzanych przez inne
funkcje nasłuchiwania POST_AUTO_BUILD
.
Z tym podejściem wiążą się jednak istotne różnice. Przed wprowadzeniem wersji
Eclipse 3.0 funkcje nasłuchiwania automatycznego budowania były zawsze wywoływane
przed funkcjami nasłuchiwania POST_CHANGE
. Z tego powodu wartość
delta odbierana przez te pierwsze była zawsze podzbiorem wartości delta
odbieranych przez funkcje nasłuchiwania POST_CHANGE
. W zasadzie ten
związek został obecnie odwrócony. Funkcje nasłuchiwania automatycznego budowania
odbierają wartość delta, która jest nadzbiorem wszystkich delt dostarczanych
do funkcji nasłuchiwania POST_CHANGE
od momentu ostatniego budowania
w tle. Tak jak wcześniej, funkcje nasłuchiwania automatycznego budowania mogą
modyfikować obszar roboczy, a funkcje nasłuchiwania post-change nie mają takiej
możliwości.
Nie jest już tak, że po zakończeniu operacji zmiany obszaru roboczego
funkcje nasłuchujące zdarzenia AUTO_BUILD
zostaną o tym
powiadomione. Opisywana zmiana prawdopodobnie nie będzie miała wpływu na kod
klienta, który rejestruje funkcje nasłuchiwania zmian zasobów za pomocą metody
IWorkspace.addResourceChangeListener(IResourceChangeListener)
,
ponieważ zdarzenia AUTO_BUILD
nigdy nie były raportowane do tych
funkcji. Jednak w przypadku klientów korzystających z metody
IWorkspace.addResourceChangeListener(IResourceChangeListener,int)
i określających maskę zdarzeń obejmującą zdarzenia AUTO_BUILD
prawdopodobnie dojdzie do błędów w wyniku opisywanej zmiany, jeśli zakłada się
w nich, kiedy funkcje nasłuchiwania automatycznego budowania są uruchamiane lub w
jakim wątku się odbywają. Przykładowo jeśli funkcja nasłuchiwania automatycznego
budowania aktualizuje model domeny w celu uwzględnienia zmian wprowadzonych w
obszarze roboczym, aktualizacja może nie zostać przeprowadzona przy ponownej
operacji zmiany obszaru roboczego. Należy zauważyć, że dotyczy to jedynie kodu
na poziomie interfejsu użytkownika. Kod na poziomie jądra wywoływany za
pośrednictwem interfejsu API może być wywoływany w ramach zasięgu interfejsu
IWorkspaceRunnable
, dlatego nie ma pewności co do dokładnej pory
wywołania nasłuchiwania zmian. Aby naprawić błędy wynikające z opisywanej
modyfikacji, należy korzystać ze zdarzenia POST_CHANGE
zamiast
funkcji nasłuchiwania budowania, jeśli konieczne jest wystąpienie powiadomienia
przed zakończeniem operacji.
Nie ma już gwarancji, że wszystkie zmiany zasobów odbywające się w ramach
dynamicznego zasięgu interfejsu IWorkspaceRunnable
zostaną
uwzględnione w pojedynczym powiadomieniu. Z mechanizmu tego można w dalszym
ciągu korzystać w celu uniknięcia niepotrzebnego budowania i powiadamiania, ale
platforma może przeprowadzić powiadomienie podczas operacji. Ta zmiana
kontraktu API prawdopodobnie nie będzie miała negatywnego wpływu na
istniejących klientów. Jest analogiczna do sytuacji, w której platforma
wywołuje okresowo metodę IWorkspace.checkpoint
podczas
długotrwałych operacji. Opisywana zmiana była spowodowana potrzebą wprowadzenia
możliwości współbieżnego modyfikowania obszaru roboczego przez wiele wątków. Po
zakończeniu modyfikowania obszaru roboczego przez jeden wątek wymagane jest
powiadomienie w celu uniknięcia problemu zaniku reakcji, nawet jeśli inne
operacje nie zostały jeszcze zakończone. Ponadto zmiana ta pozwala użytkownikom
rozpocząć pracę na zbiorze zasobów przed zakończeniem operacji. Przykładowo
użytkownik może rozpocząć przeglądanie plików w projekcie, który jest w dalszym
ciągu pobierany. Nowa metoda IWorkspace.run(IWorkspaceRunnable,
ISchedulingRule, int, IProgressMonitor)
ma opcjonalną flagę
AVOID_UPDATE
, której operacje mogą używać jako sygnału dla
platformy w celu określenia, czy mają być przeprowadzane okresowe aktualizacje.
Elementy, których dotyczy ta zmiana: Wtyczki,
które wnoszą rozszerzenia do punktu rozszerzenia
org.eclipse.core.runtime.urlHandlers
.
Opis: Zmieniono kontrakt dla punktu rozszerzenia
org.eclipse.core.runtime.urlHandlers
w celu użycia procedury
obsługi strumienia URL udostępnianej przez usługi OSGi. Obsługa OSGi jest
lepsza od tej, która była dostępna w środowisku Eclipse 2.1, i poprawnie
współpracuje z dynamicznymi procedurami obsługi. Ze względu na różne problemy
projektowe z podstawowym mechanizmem obsługi URL Java, klasy URLStreamHandler
zarejestrowane za pomocą procedury obsługi OSGi muszą implementować interfejs
org.osgi.service.url.URLStreamHandlerService
.
Wymagana akcja: We wcześniejszych wersjach klasa
z procedurą obsługi musiała implementować interfejs java.net.URLStreamHandler
i rozszerzać punkt rozszerzenia urlHandlers. Punkt ten nie jest już obsługiwany
i należy zaktualizować procedurę obsługi w celu zaimplementowania interfejsu
org.osgi.service.url.URLStreamHandlerService
. Środowisko OSGi
udostępnia abstrakcyjną klasę bazową
(org.osgi.service.url.AbstractURLStreamHandlerService
), którą
można łatwo wykorzystać do utworzenia podklasy, aby przeprowadzić wspomnianą
aktualizację.
Zamiast rejestrować procedurę obsługi za pomocą punktu rozszerzenia, wtyczki muszą obecnie rejestrować procedury obsługi jako usługi. Na przykład:
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);
Elementy, których dotyczy ta zmiana: Wtyczki dostarczające pakiety udostępniane również przez inne wtyczki. Dotyczy to jedynie nielicznych wtyczek, a niektóre z nich mogą nawet skorzystać na wprowadzonej zmianie (patrz niżej).
Opis: W środowisku Eclipse 2.x program ładujący klasy wyszukuje klasy w następującym porządku: (1) program ładujący klasy macierzystej (w praktyce jest to program ładujący startowej klasy Java), następnie (2) treść jego własnej ścieżki klasy i wreszcie (3) wszystkie jego wymagania wstępne w zadeklarowanym porządku. Specyfikacja OSGi oferuje możliwość optymalizacji tego modelu. W tym podejściu program ładujący klasy sprawdzi (1) program ładujący klasy macierzystej (znowu, jest to ostatecznie program ładujący startowej klasy Java), następnie albo (2a) pojedyncze wymaganie wstępne, które udostępnia klasy w przeszukiwanym pakiecie, albo (2b) pozycje z jego własnej ścieżki klasy dla wymaganej klasy.
Program ładujący ustala, czy sprawdza samego siebie lub swoje wymagania wstępne na podstawie zaimportowanych i wymaganych pakietów. Informacje te pobiera się z treści wtyczki w przypadku tradycyjnych wtyczek albo określa bezpośrednio w przypadku wtyczek z jawnym manifestem pakunku OSGi. W obu przypadkach wiadomo a priori, które programy ładujące klas dostarczą klasy dla określonych pakietów. Pozwala to na zwiększenie wydajności oraz stanowi rozwiązanie dla stale powracającego problemu, gdy wiele wymagań wstępnych wnosi te same klasy.
Za przykład mogą tutaj posłużyć wtyczki Xerces i Xalan - oba zawierają różne klasy z pakietów org.xml. Przy pierwszym podejściu wtyczka Xerces zobaczyłaby swoją kopię tych klas, a wtyczka Xalan zobaczyłaby ich kopię. Ponieważ te wtyczki muszą się ze sobą komunikować, wystąpią wyjątki ClassCastExceptions. Przy drugim podejściu tylko jedna z tych wtyczek wnosi zduplikowane klasy i obie widzą te same kopie.
Wymagana akcja: Wymagana akcja zależy od szczegółów danego przypadku użycia. Programiści, których dotyczy ta zmiana, musza przejrzeć ścieżkę klasy i rozwiązać potencjalne konflikty.
Elementy, których dotyczy ta zmiana: Wtyczki, które oczekują stale ustawionej domeny ochrony swoich programów ładujących klas.
Opis: W środowisku Eclipse 2.1 programy ładujące klas wtyczek (java.security.SecureClassloaders) miały zawsze ustawioną domenę ochrony. W wersji Eclipse 3.0 programy ładujące klas nie rozszerzają klasy SecureClassloader i ustawiają domenę ochrony tylko wtedy, gdy włączona jest ochrona Java (nie jest tak domyślnie).
Wymagana akcja: Wymagana akcja będzie zależeć od konkretnego scenariusza, w którym wtyczka korzysta z domeny ochrony.
Elementy, których dotyczy ta zmiana: Wtyczki, które rzutują obiekty typu org.eclipse.core.runtime.IPlugin* na org.eclipse.core.runtime.model.Plugin*Model. Choć związek między tymi interfejsami i klasami modeli nie jest określony w interfejsie API środowiska Eclipse 2.1, zwracamy uwagę na niniejszą zmianę, ponieważ znaleziono przypadki wtyczek polegających na tym związku w implementacji wersji 2.1.
Opis: Interfejs API środowiska Eclipse udostępnia zestaw interfejsów
(np. IPluginDescriptor
) i tzw. klasy "modeli" (np.
PluginDescriptorModel
) związane z wtyczkami i
rejestrem wtyczek. W implementacji Eclipse 2.1 zdarza się, że klasy
modeli implementują te interfejsy. W nowym środowisku wykonawczym bazującym na
specyfikacji OSGi rejestr wtyczek został znacznie przeprojektowany,
aby umożliwić oddzielenie aspektów ładowania klas i wymagań wstępnych od
aspektów rozszerzeń i punktów rozszerzeń. Z tego względu środowisko wykonawcze
platformy Eclipse 3.0 nie jest w stanie zachować relacji implementacji obecnej
w wersji 2.1.
Wymagana akcja: Należy przebudować wtyczki, które polegają na tym związku niebędącym związkiem API, uwzględniając konkretny przypadek użycia. Więcej informacji na ten temat można znaleźć w sekcji niniejszego dokumentu, która traktuje o zalecanych zmianach, a także w dokumentacji Javadoc dotyczącej powiązanych klas i metod.
Elementy, których dotyczy ta zmiana: Wtyczki
korzystające z interfejsu org.eclipse.core.runtime.ILibrary
.
Opis: Nowe środowisko wykonawcze przechowuje pozycje ścieżek klas w innej formie, która nie jest kompatybilna z platformą Eclipse. Powoduje to, że warstwa kompatybilności nie jest w stanie prawidłowo modelować bazowych struktur OSGi jako obiektów ILibrary. Obsługa kompatybilności środowiska wykonawczego tworzy obiekty ILibrary, ale musi zakładać wartości domyślne dla wszystkich elementów z wyjątkiem ścieżki biblioteki.
Wymagana akcja: Użytkownicy interfejsu ILibrary powinni wziąć pod
uwagę uzyskanie dostępu do wartości nagłówka (np. Bundle-Classpath
)
z poziomu odpowiedniego pakunku (patrz Bundle.getHeaders()
) i
użycie klasy pomocniczej ManifestElement
do interpretacji wpisów.
Więcej szczegółów zawiera dokumentacja Javadoc tej klasy.
Elementy, których dotyczy ta zmiana: Wtyczki z założeniami co do struktury instalacji, położenia i układu lokalnego systemu plików.
Opis: Metody takie jak IPluginDescriptor.getInstallURL()
zwracają adresy URL w określonej formie. Choć forma ta nie jest wyraźne
opisana, różne wtyczki czynią odnośne założenia na podstawie bieżącej
implementacji. Przykładowo mogą oczekiwać adresu URL w formie
file:
oraz skorzystać z metody URL.getFile() i użyć manipulacji
java.io.File
na zwróconym wyniku. Do tej pory takie podejście
sprawdzało się, chociaż istniało ryzyko wystąpienia nieprawidłowości. Przykładowo jeśli
wtyczka jest zainstalowana na serwerze WWW, możliwe, że zostanie
zwrócony adres URL w formie http:
. Nowe środowisko wykonawcze
Eclipse 3.0 jest jeszcze bardziej elastyczne i otwiera nowe możliwości w
zakresie konfiguracji wykonywania (np. możliwość zachowania całych wtyczek w plikach JAR zamiast w postaci rozpakowanej w katalogach). Choć nowe
środowisko wykonawcze bazujące na specyfikacji OSGi nie odbiega całkowicie od
interfejsu API z wersji 2.1 API, powoduje więcej przypadków, w których
założenia obecne w bieżących wtyczkach są niepoprawne.
Wymagane działania: Autorzy wtyczek powinni się upewnić,
że potrzebne informacje są dostępne za pośrednictwem metody
getResource()
(i znajdują się w ścieżce klasy), albo powinni użyć
odpowiedniego interfejsu API w celu uzyskania dostępu do treści wtyczki (np. Bundle.getEntry(String)
).
Elementy, których dotyczy ta zmiana: Kod spoza wtyczek,
który wywołuje określone metody z klasy
org.eclipse.core.boot.BootLoader
.
Opis: Metody statyczne BootLoader.startup(), shutdown() oraz run() zostały przeniesione do klasy org.eclipse.core.runtime.adaptor.EclipseStarter, która wchodzi w skład środowiska OSGi. Ten interfejs API łączy metodę main() w pliku startup.jar ze środowiskiem OSGi/środowiskiem wykonawczym Eclipse. Restrukturyzacja środowiska wykonawczego uniemożliwiła pozostawienie tych metod w klasie BootLoader. Stara klasa BootLoader znajduje się teraz w warstwie kompatybilności środowiska wykonawczego i jest nieaktualna, a wymienione metody zostały zablokowane.
Nie ma zastępnika dla starej metody BootLoader.getRunnable(), ponieważ środowisko wykonawcze nie może obsługiwać przejęcia pojedynczych aplikacji. Użytkownicy muszą zamiast tego wskazać odpowiednią aplikację podczas uruchamiania platformy.
Wymagana akcja: Ten interfejs API jest na ogół używany przez nieliczną grupę użytkowników (nie można z niego skorzystać z poziomu wtyczki środowiska Eclipse). W rzadkich przypadkach jego użycia należy zaadaptować kod w celu wykorzystania odpowiednich metod z klasy EclipseStarter.
Elementy, których dotyczy ta zmiana: Wszystkie wtyczki.
Opis: W środowisku Eclipse 2.1 wiersz bin.includes w pliku build.properties nie musiał zawierać listy plików JAR z odpowiednich deklaracji bibliotek w pliku plugin.xml. Pliki te były dodawane za darmo. W wersji Eclipse 3.0 lista plików w sekcji bin.includes w pliku build.properties ma charakter wyczerpujący i musi zawierać wszystkie pliki, które autor wtyczki chce zawrzeć w tworzonej wtyczce podczas budowy lub eksportu.
Wymagana akcja: Należy się upewnić, że wiersz bin.includes w pliku build.properties zawiera wszystkie pliki JAR wymienione w pliku plugin.xml.
Elementy, których dotyczy ta zmiana: Wtyczki prezentujące interfejs API z elementami ze zmienionego interfejsu API środowiska wykonawczego.
Opis: Różne wtyczki prezentują interfejs API zawierający elementy ze zmienionego interfejsu API środowiska wykonawczego. Biorąc pod uwagę opisane tutaj zmiany wprowadzone w środowisku wykonawczym Eclipse 3.0, należy zrewidować użycie interfejsu API tego środowiska we wtyczkach klientów.
Wymagana akcja: Ten scenariusz jest dość rzadki, ponieważ interfejs API środowiska wykonawczego platformy Eclipse uległ zmianie tylko w nieznacznym stopniu. W zależności od sytuacji może zaistnieć konieczność zmodyfikowania interfejsu API stosowanego przez klienta bądź dalszego korzystania z warstwy zgodności.
Elementy, których dotyczy ta zmiana: Wtyczki
korzystające z metody org.eclipse.core.runtime.Platform.parsePlugins(...,
Factory).
Opis: Metoda
org.eclipse.core.runtime.Platform.parsePlugins(..., Factory)
została przeniesiona. Interfejs API powiązany z argumentem Factory został
przeniesiony z wtyczki org.eclipse.core.runtime do wtyczki
org.eclipse.core.runtime.compatibility (która zależy od wtyczki środowiska
wykonawczego). W wyniku tej zmiany metoda analizy została również przeniesiona.
Wymagana akcja: Użytkownicy tej metody powinni korzystać z tej
samej metody w klasie
org.eclipse.core.runtime.model.PluginRegistryModel
.
Elementy, których dotyczy ta zmiana: Wtyczki określające kod w ścieżce klasy, ale nie dostarczające tego kodu (tzn. plik JAR jest dostarczany przez fragment; np. wtyczkę org.eclipse.swt).
Opis: Nowe środowisko wykonawcze musi przekształcić pliki plug.xml w pliki manifest.mf w tle. Odbywa się to z użyciem prostej transformacji mechanicznej i analizy plików jar zadeklarowanych i dostarczonych przez wtyczkę. W sytuacji gdy wtyczka deklaruje plik jar w ścieżce klasy, ale go nie dostarcza, nie ma kodu, który można poddać analizie, i konwerter wtyczki nie jest w stanie wygenerować poprawnego pliku manifest.mf.
Wymagana akcja: Dostawcy tego rodzaju wtyczek muszą je zmodyfikować, aby dostarczały odpowiedni plik jar, albo ręcznie przebudować plik META-INF/MANIFEST.MF pod kątem wtyczki. Zwykle za pomocą środowiska PDE uzyskuje się początkowy manifest, a następnie dodaje odpowiedni nagłówek Provide-Package.
Elementy, których dotyczy ta zmiana: Skrypty (np. pliki build.xml narzędzia Ant) definiujące ścieżki klas z katalogami klas i plikami jar powiązanymi ze środowiskiem wykonawczym.
Opis: Nowe środowisko wykonawcze zawiera klika nowych wtyczek i plików jar. Ich wprowadzenie wynikało z refaktoryzacji środowiska
wykonawczego na konfigurowalne fragmenty. W większości sytuacji zmiany te mają
charakter niewidoczny dla użytkownika. Jeśli jednak wykorzystuje się
niestandardowe skrypty build.xml (lub podobne), które kompilują kod w
odniesieniu do wtyczki org.eclipse.core.runtime
, należy je
zaktualizować, aby mogły działać poprawnie. Typowy skrypt zawiera wpis ścieżki
klasy w czynności <javac>, która odwołuje się do wtyczki
org.eclipse.core.runtime
w następujący sposób:
../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar
Wtyczka środowiska wykonawczego nadal zawiera znaczną część kodu
oryginalnego środowiska. Niektóre elementy środowiska wykonawczego, które znajdują się w nim wyłącznie w celu zachowania zgodności, są zawarte we wtyczce zgodności (org.eclipse.core.runtime.compatibility
). Większość nowego kodu znajduje się w zestawie wtyczek
org.eclipse.osgi.*
.
Wymagana akcja: Programiści powinni w razie potrzeby dodać poniższe wpisy w celu wyeliminowania błędów kompilacji. Choć przedstawiono tutaj kompletny zestaw dostarczanych plików jar, w typowych zastosowaniach wymagany jest tylko ich podzbiór znajdujący się w ścieżce klasy podczas kompilacji. Jak zwykle uwzględnienie katalogów /bin jest opcjonalne. Przedstawione wpisy zestawiono w logicznych grupach według wtyczki:
Oprócz tego w szczególnych przypadkach mogą być wymagane następujące pliki jar:
Aktualizując tego rodzaju skrypty, można jednocześnie wyczyścić (tzn.
usunąć) odwołania do wtyczki org.eclipse.core.boot
. Jest on
przestarzały i nie zawiera już żadnego kodu. Odpowiadające mu wpisy można
pozostawić w ścieżce klasy, ale nie są one do niczego potrzebne i najlepiej je
usunąć. Wpis do usunięcia to:
../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar
Elementy, których dotyczy ta zmiana: Skrypty (np. pliki build.xml narzędzia Ant) korzystające z czynności eclipse.buildScript.
Opis: Budowanie w środowisku PDE wiąże się z wprowadzeniem nowej właściwości do czynności eclipse.buildScript, która pozwala sterować generowaniem skryptów budowania wtyczek. Zmiana była spowodowana wprowadzeniem nowego środowiska wykonawczego bazującego na specyfikacji OSGi.
Wymagana akcja: Aby użyć środowiska Eclipse 3.0 do budowy produktu opartego na wersji 2.1, należy wprowadzić w czynności eclipse.buildScript właściwość "buildingOSGi" i ustawić ją na false. Na przykład:
<eclipse.buildScript ... buildingOSGi="false"/>
Elementy, których dotyczy ta zmiana: Skrypty (np. pliki build.xml narzędzia Ant) korzystające z czynności eclipse.buildScript.
Opis: Budowanie w środowisku PDE wiąże się z wprowadzeniem nowej właściwości do czynności eclipse.buildScript, która pozwala sterować generowaniem skryptów budowania wtyczek. Zmiana była spowodowana wprowadzeniem nowego środowiska wykonawczego bazującego na specyfikacji OSGi.
Wymagana akcja: Aby użyć środowiska Eclipse 3.0 do budowy produktu opartego na wersji 2.1, należy wprowadzić w czynności eclipse.buildScript właściwość "buildingOSGi" i ustawić ją na false. Na przykład:
<eclipse.buildScript ... buildingOSGi="false"/>
Elementy, których dotyczy ta zmiana: Skrypty (np. pliki build.xml narzędzia Ant) korzystające z czynności eclipse.buildScript.
Opis: Budowanie w środowisku PDE wiąże się ze zmianą zachowania czynności eclipse.fetch w celu ułatwienia zautomatyzowanego budowania na platformie Eclipse. Elementy style obsługują teraz tylko pojedyncze wpisy, a elementy scriptName są zawsze ignorowane.
Wymagana akcja: Jeśli w znaczniku "elements" wywołania eclipse.fetch występuje lista pozycji, należy je rozdzielić na kilka wywołań. Jeśli element scriptName jest ustawiany, należy zwrócić uwagę, że wygenerowany skrypt pobierania nosi zawsze nazwę "fetch_{elementId}". Na przykład:
<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>
jest przekształcany w
<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../> <eclipse.fetch elements="feature@org.eclipse.platform" .../>
Plik install.ini nie jest już dostępny. Zastąpiono go plikiem config.ini w podkatalogu configuration. Produkty, które korzystały z pliku install.ini do określenia składnika podstawowego (np. w celu udostępnienia informacji o oznakowaniu marką), muszą teraz zamiast niego modyfikować plik config.ini. Oprócz zmiany nazwy pliku zmianie uległy również nazwy kluczy.
Wartość klucza feature.default.id z wersji 2.1 należy ustawić jako wartość nowego klucza eclipse.product. Wartość klucza eclipse.application należy ustawić na "org.eclipse.ui.ide.workbench".
Ostatnia kwestia to obraz używany na ekranie startowym - w wersji 2.1 był to zawsze plik splash.bmp w katalogu marki wtyczki. W wersji 3.0 położenie obrazu startowego jest określane bezpośrednio przez klucz osgi.splashPath w pliku config.ini.