Najczęściej zadawane pytania dotyczące migrowania modułów dodatkowych do środowiska Eclipse 3.0

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 moduł dodatkowy z wersji 2.1 będzie działał na platformie Eclipse 3.0?

Tak, z kilkoma wyjątkami. Jeśli moduł dodatkowy 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 moduł dodatkowy korzysta z tych elementów, nie będzie działał w nowej wersji.

Moduł dodatkowy w wersji 2.1 korzysta z klas w pakietach wewnętrznych. Czy będzie nadal działał na platformie Eclipse 3.0?

Jeśli moduł dodatkowy 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ć moduł dodatkowy w środowisku Eclipse 3.0 bez konieczności modyfikowania go?

Należy zainstalować moduł dodatkowy z wersji 2.1 w podkatalogu eclipse/plugins/ produktu bazującego na platformie Eclipse 3.0 i zrestartować tę platformę. Środowisko Eclipse rozpozna, że ten moduł jest nieprzekształconym modułem dodatkowym 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 modułów dodatkowych oraz nazw punktów rozszerzeń platformy.

Czy moduł dodatkowy z wersji 2.1 wymaga zmodyfikowania, aby poprawnie kompilował 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 modułów dodatkowych. Jeśli moduł napisany dla wersji 2.1 wymaga ponownej kompilacji, należy przeprowadzić migrację tego modułu do wersji 3.0 przed dalszą obróbką pod kątem tej wersji.

W jaki sposób można przeprowadzić migrację modułu dodatkowego do środowiska Eclipse 3.0?

Po załadowaniu (lub zaimportowaniu) projektu modułu dodatkowego 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 modułu na format wersji 3.0 i automatycznie dostosować listę wymaganych modułów dodatkowych i odniesień platformy do punktów rozszerzeń, których nazwy uległy zmianie. Po przeprowadzeniu tych czynności skompilowanie i wykonywanie kodu modułu dodatkowego powinno w większości przypadków przebiegać bezproblemowo. Należy jeszcze przejrzeć kod modułu, 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 modułu dodatkowego 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 w modułach dodatkowych.

Czy po przeprowadzeniu migracji modułu dodatkowego do środowiska Eclipse 3.0 można będzie zainstalować i uruchomić wynikowy moduł binarny 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 modułu dodatkowego 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 modułu dodatkowego org.eclipse.core.runtime do nowego modułu org.eclipse.core.runtime.compatibility. Domyślnie nowo tworzone moduły dodatkowe zależą od modułu org.eclipse.core.runtime i powinny bazować wyłącznie na aktualnych funkcjach API środowiska wykonawczego. Z drugiej strony istniejące moduły dodatkowe migrowane z wersji 2.1 zależą domyślnie od modułu org.eclipse.core.runtime.compatibility i mogą również odwoływać się do starszych funkcji API (moduł org.eclipse.core.runtime.compatibility umożliwia reeksport funkcji API modułu org.eclipse.core.runtime). Choć moduł 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 modułu dodatkowego org.eclipse.ui.workbench.compatibility?

Org.eclipse.ui.workbench.compatibility to fragment modułu dodatkowego, który udostępnia rozszerzoną kompatybilność binarną dla modułów dodatkowych 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 moduły dodatkowe z wersji 2.1 bez ich modyfikowania. Należy jednak zauważyć, że moduły dodatkowe 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 w module 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).