W tej sekcji opisano zmiany, jakie należy wprowadzić we wtyczce w wersji 3.1, aby wykorzystać mechanizmy i interfejsy API oferowane przez wersję 3.2.
W środowisku Eclipse 3.2 dostępna jest nowa infrastruktura służąca do tworzenia powiązań między konfiguracjami startowymi a zasobami. Powiązania te umożliwiają filtrowanie konfiguracji startowych w zależności od zasobów, a także opcjonalne usuwanie takich konfiguracji w przypadku usunięcia związanego z nimi projektu. Okno dialogowe uruchamiania zostało rozszerzone o obsługę zestawu filtrów, które pozwalają opcjonalnie ukrywać konfiguracje dotyczące zamkniętych i usuniętych projektów. Ponadto w oknie uruchamiania obsługiwane jest filtrowanie na podstawie zestawów roboczych wybranych w aktywnym oknie środowiska roboczego, które można także wybierać w oknie dialogowym uruchamiania.
Za zarządzanie przypisaniem zasobów do konfiguracji startowych odpowiada klient. Interfejs ILaunchConfigurationWorkingCopy
został uzupełniony o funkcję API służącą do ustawiania zasobów powiązanych z daną konfiguracją, a w przypadku interfejsu ILaunchConfiguration
dodana została funkcja API umożliwiająca pobieranie zasobów związanych z daną konfiguracją. Podczas migracji należy wziąć pod uwagę na przykład karty uruchamiania, skróty uruchamiania oraz uczestników refaktoryzacji. Kod służący do tworzenia bądź modyfikowania konfiguracji startowych powinien także umożliwiać aktualizację przypisania zasobów.
W środowisku Eclipse 3.2 dostępna jest nowa infrastruktura umożliwiająca migrację konfiguracji startowych w sposób zapewniający zgodność z nowymi narzędziami. W wersji 3.2 dodano na przykład obsługę filtrowania konfiguracji startowych w zależności od zasobów. Aby wykorzystać nową opcję, konfiguracje startowe należy zaktualizować, dodając odpowiednie przypisania zasobów. Użytkownicy mogą dokonywać migracji konfiguracji startowych ręcznie w ramach obszaru roboczego, korzystając z przycisku Migruj na stronie preferencji
Wykonywanie/debugowanie > Uruchamianie > Konfiguracje startowe.
W punkcie rozszerzenia launchConfigurationTypes
dodany został nowy, opcjonalny atrybut metody delegowanej migracji, za pomocą którego określa się klasę służącą do implementacji nowego interfejsu ILaunchConfigurationMigrationDelegate
. Atrybut metody delegowanej migracji odpowiada za zidentyfikowanie elementów nadających się do migracji i przeprowadzenie ich migracji.
W punkcie rozszerzenia launchModes
dodany został nowy, opcjonalny atrybut umożliwiając właściwą obsługę eksternalizacji etykiet akcji menu kaskadowego uruchamiania. Klienty wnoszące tryby uruchamiania powinny określać właściwą etykietę, która ma być stosowana do uruchamiania menu kaskadowych (takich jak "Wykonaj jako"). Nowy atrybut nosi nazwę launchAsLabel
. W ramach platformy dostępne są właściwe etykiety trybów wykonywania, debugowania i uruchamiania profilu. Aby zapewnić zgodność wsteczną, jeśli w przypadku danego trybu uruchamiania nie określono nowego atrybutu, etykiety menu kaskadowego są generowane w dotychczasowy sposób (za pomocą klasy MessageFormat
z elementem "{0} jako
"). Patrz informacje o pokrewnym błędzie 105235.
Biblioteka akiet ICU4J to w rzeczywistości zbiór bibliotek języka Java, które zapewniają obszerniejszą obsługę kodu Unicode oraz globalizacji i wersji narodowych oprogramowania. Aby udostępnić oferowaną funkcjonalność użytkownikom środowiska Eclipse, biblioteka ICU4J została dodanya do kompilacji platformy w wersji 3.2. Występuje ona w ramach tej kompilacji jako wtyczka com.ibm.icu. Dzięki temu środowisko Eclipse 3.2 pozwala korzystać z interfejsów API biblioteki ICU.
Migrację kodu aplikacji można przeprowadzać przyrostowo. Oznacza to, że korzystanie z zalet biblioteki ICU4J nie wymaga pełnego wdrożenia wszystkich jej funkcji. Więcej informacji na temat migracji kodu w celu korzystania z biblioteki ICU4J zawiera strona dotycząca biblioteki ICU4J w internetowej encyklopedii dotyczącej środowiska Eclipse.
Dodanie wtyczki biblioteki ICU4J powoduje zwiększenie objętości elementu o około 3 MB. Niektóre aplikacje mogą nie przyjmować wtyczki biblioteki ICU4J, jeśli wielkość aplikacji ma większe znaczenie niż realizacja funkcji tej biblioteki. W takim przypadku na stronie kompilacji platformy Eclipse można uzyskać wtyczkę zastępczą (com.ibm.icu.base). Po pobraniu wtyczki należy usunąć dotychczasową wtyczkę com.ibm.icu wraz z odpowiednikiem źródłowym z katalogu /plugins
, a następnie umieścić w nim wtyczkę zastępczą. Jest to konieczne, ponieważ w wersji 3.2 platformy Eclipse wdrożono interfejsy API biblioteki ICU, w związku z czym usunięcie wtyczki biblioteki ICU spowodowałoby błędy kompilacji w kodzie platformy. Wtyczka zastępcza ma rozmiar około 100 kB. Jej działanie polega na wywoływaniu implementacji najczęściej stosowanych klas i interfejsów API biblioteki ICU4J w ramach domyślnego pakietu JDK. Szczegółowe informacje na temat korzystania z wtyczki zastępczej biblioteki ICU4J zawiera strona dotycząca biblioteki ICU4J w internetowej encyklopedii dotyczącej środowiska Eclipse.
Aby zapewnić obsługę biblioteki ICU4J w pakiecie JFace, konieczne było zmodyfikowanie interfejsów API w sposób pozwalający zapobiec tworzeniu odwołań do klas biblioteki ICU w tych interfejsach. W ten sposób dodano:
org.eclipse.jface.viewers.ViewerComparator
, której podklasą jest obecnie klasa org.eclipse.jface.viewers.ViewerSorter
;org.eclipse.jface.viewers.StructuredViewer
umożliwiające obsługę dodatkowej klasy org.eclipse.jface.viewers.ViewerComparator
.W klasie ViewerSorter
występuje metoda publiczna getCollator()
, która zwraca klasę java.text.Collator
. Metoda jest interfejsem API, w związku z czym nie można było jej zmienić w prosty sposób umożliwiający korzystanie z klasy Collator
biblioteki ICU. Ponadto podklasy biblioteki ICU nie mogą być elementami interfejsu API (sygnaturami), ponieważ bezpośrednia zależność wtyczek od biblioteki ICU uniemożliwiłaby autonomiczne działanie pakietu JFace (wraz z narzędziami SWT). W związku z tymi ograniczeniami dodano klasę ViewerComparator
, która korzysta z interfejsu java.util.Comparator
zamiast klasy Collator
biblioteki ICU. Stało się tak dlatego, że interfejs java.util.Comparator
jest implementowany przez klasę Collator
biblioteki ICU, w związku z czym dowolna klasa StructuredViewer
może korzystać z klasy Collator
biblioteki ICU zamiast klasy java.text.Collator
, ale w pakiecie JFace nie ma potrzeby dodawania zależności od wtyczki biblioteki ICU4J.
Obie metody dodane do klasy StructuredViewer
umożliwiają korzystanie z klasy Collator
biblioteki ICU do sortowania treści przeglądarki przy użyciu klasy ViewerComparator
, a nie klasy ViewerSorter
. Zaleca się stosowanie tych metod we wszystkich klasach StructuredViewer
w celu uzyskiwania bądź ustawiania modułu sortującego (porównującego) przeglądarki zamiast metod getSorter()
i setSorter(ViewerSorter)
.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
Pakunek org.eclipse.equinox.common zawiera kilka nowych klas interfejsów API (np. Assert
i ListenerList
), które noszą wspólne nazwy. Jeśli w kodzie użytkownika występuje klasa o takiej samej nazwie wykorzystująca instrukcje import* do importowania klas lokalnych i klas środowiska wykonawczego, może zostać wyświetlony następujący komunikat:
The type ABC is ambiguous
Reorganizacja funkcji importu i wybór odpowiedniego źródła importu powinny rozwiązać ten problem.
W związku z przeniesieniem kodu do nowych wtyczek środowiska wykonawczego w niestandardowych skryptach odwołujących się jawnie do elementu org.eclispe.core.runtime może być konieczne dodanie jednej lub kilku z następujących wtyczek: