Dlaczego interfejs API środowiska Eclipse zmienił się tak, że wersje 2.1 i 3.0 nie są w pełni kompatybilne?
Środowisko Eclipse 3.0 stanowi ewolucyjne rozwinięcie platformy Eclipse 2.1. Na kilku obszarach nie udało się jednak zachować ciągłości ewolucyjnej tego środowiska z zachowaniem idealnej kompatybilności między wersjami. Cztery główne czynniki powodujące powstanie niekompatybilności są następujące:
Więcej informacji zawiera lista konkretnych obszarów niekompatybilności.
Czy wtyczka z wersji 2.1 będzie działać na platformie Eclipse 3.0?
Tak, z kilkoma wyjątkami. Jeśli wtyczka bazuje wyłącznie na interfejsach API środowiska Eclipse 2.1, będzie nadal działać poprawnie w wersji 3.0. Nieliczne wyjątki od tej reguły dotyczą tych elementów interfejsu API, dla których wprowadzenie zmian w wersji 3.0 z zachowaniem kompatybilności było niemożliwe. Jeśli wtyczka korzysta z tych elementów, nie będzie działać w nowej wersji.
Wtyczka w wersji 2.1 korzysta z klas w pakietach wewnętrznych. Czy będzie nadal działał na platformie Eclipse 3.0?
Jeśli wtyczka bazuje na klasach wewnętrznych lub na mechanizmach, których nie określono w ramach interfejsu API platformy Eclipse 2.1, nie jest możliwe kategoryczne stwierdzenie z góry, czy będzie bądź też nie będzie działać w wersji 3.0. Należy go wypróbować.
W jaki sposób można uruchomić wtyczkę w środowisku Eclipse 3.0 bez konieczności modyfikowania jej?
Należy zainstalować wtyczkę z wersji 2.1 w podkatalogu eclipse/plugins/ produktu bazującego na platformie Eclipse 3.0 i zrestartować tę platformę. Środowisko Eclipse rozpozna, że ta wtyczka jest nieprzekształconą wtyczką z wersji 2.1 (na podstawie nagłówka w pliku plugin.xml) i automatycznie wprowadzi odpowiednie poprawki mające na celu uwzględnienie zmian w zakresie zależności wtyczek oraz nazw punktów rozszerzeń platformy.
Czy wtyczka z wersji 2.1 wymaga zmodyfikowania, aby poprawnie kompilowała się w środowisku Eclipse 3.0?
Tak - we wszystkich przypadkach. Między środowiskiem Eclipse w wersji 2.1 i 3.0 występują pewne różnice, które wiążą się z koniecznością zmodyfikowania wszystkich migrowanych wtyczek. Jeśli wtyczka napisana dla wersji 2.1 wymaga ponownej kompilacji, należy przeprowadzić migrację tej wtyczki do wersji 3.0 przed dalszą obróbką pod kątem tej wersji.
W jaki sposób można przeprowadzić migrację wtyczki do środowiska Eclipse 3.0?
Po załadowaniu (lub zaimportowaniu) projektu wtyczki do obszaru roboczego Eclipse 3.0 należy użyć opcji Narzędzia PDE > Migruj do 3.0 (z menu kontekstowego projektu), aby przekształcić manifest wtyczki na format wersji 3.0 i automatycznie dostosować listę wymaganych wtyczek i odwołań platformy do punktów rozszerzeń, których nazwy uległy zmianie. Po przeprowadzeniu tych czynności skompilowanie i wykonywanie kodu wtyczki powinno w większości przypadków przebiegać bezproblemowo. Należy jeszcze przejrzeć kod wtyczki, aby upewnić się, że nie jest zależny od żadnego z obszarów, w których nastąpiły niekompatybilne zmiany w zakresie interfejsu API.
Czy można wierzyć, że dla wtyczki pojawią się błędy kompilacji lub ostrzeżenia, jeśli bazuje on na interfejsie API, który uległ zmianie powodującej brak kompatybilności?
Nie. Istnieją obszary niekompatybilnych modyfikacji, które nie są oznaczane przez kompilator Java.
Czy można bezpiecznie zignorować ostrzeżenia w kodzie spowodowane użyciem nieaktualnego interfejsu API?
Na krótką metę, tak. Tam gdzie to możliwe, przestarzałe interfejsy API są oznaczane jako nieaktualne, a nie usuwane, i nadal działają (dotyczy to jednak tylko sytuacji spełniających określone warunki). Dlatego chociaż nie zachodzi zwykle pilna potrzeba usunięcia nieaktualnego interfejsu API, uznanie go za przestarzały oznacza, że dostępny jest obecnie lepszy sposób zrealizowania danego celu. Należy możliwie jak najwcześniej odchodzić od korzystania z nieaktualnych interfejsów API we wtyczkach.
Czy po przeprowadzeniu migracji wtyczki do środowiska Eclipse 3.0 można będzie zainstalować i uruchomić wynikową wtyczkę binarną na platformie Eclipse 2.1?
Nie. Taka możliwość nie jest obsługiwana i prawdopodobnie nie byłoby to możliwe ze względu na zmienione nazwy punktów rozszerzeń.
Jakie jest przeznaczenie wtyczki org.eclipse.core.runtime.compatibility?
Przejście w wersji 3.0 na środowisko wykonawcze bazujące na specyfikacji OSGi spowodowało, że niektóre z istniejących funkcji API głównego środowiska wykonawczego stały się przestarzałe. Tam gdzie było to możliwe, przestarzałe funkcje API w pakietach org.eclipse.core.runtime.* oraz odpowiednie implementacje zostały przeniesione z wtyczki org.eclipse.core.runtime do nowej wtyczki org.eclipse.core.runtime.compatibility. Domyślnie nowo tworzone wtyczki zależą od wtyczki org.eclipse.core.runtime i powinny bazować wyłącznie na aktualnych funkcjach API środowiska wykonawczego. Z drugiej strony istniejące wtyczki migrowane z wersji 2.1 zależą domyślnie od wtyczki org.eclipse.core.runtime.compatibility i mogą również odwoływać się do starszych funkcji API (wtyczka org.eclipse.core.runtime.compatibility umożliwia reeksport funkcji API wtyczki org.eclipse.core.runtime). Choć wtyczka org.eclipse.core.runtime.compatibility może być dołączany do różnych konfiguracji środowiska IDE na platformie Eclipse, stanowi zbędny balast, który najprawdopodobniej będzie pomijany w produktach bazujących na konfiguracjach RCP.
Jakie jest przeznaczenie wtyczki org.eclipse.ui.workbench.compatibility?
Org.eclipse.ui.workbench.compatibility to fragment wtyczki, który udostępnia rozszerzoną kompatybilność binarną dla wtyczek z wersji 2.1 uruchamianych w produktach bazujących na platformie Eclipse 3.0. W wersji 3.0 sześć metod jawnie zależnych od interfejsu IFile lub IMarker przeniesiono z interfejsu org.eclipse.ui.IWorkbenchPage, aby wyraźnie oddzielić środowisko robocze od obszaru roboczego i zasobów. Fragment org.eclipse.ui.workbench.compatibility umożliwia ponowne dodanie tych metod, tak aby można było uruchamiać istniejące wtyczki z wersji 2.1 bez ich modyfikowania. Należy jednak zauważyć, że wtyczki migrowane do wersji 3.0 odwołujące się do przeniesionych metod będą powodowały błędy kompilacji, które można rozwiązać wyłącznie przez wywołanie metod zastępujących te starsze metody, zlokalizowanych obecnie we wtyczce org.eclipse.ui.ide.IDE.
Metody IWorkbenchPage, których dotyczą powyższe uwagi, to: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean) oraz openSystemEditor(IFile).