Zarządzanie wtyczkami w Eclipse - Extension Location
Z Jacek Laskowski - Wiki Projektanta Java EE
Wyobraź sobie sytuację, w której instalujesz produkt, którego jedną z cech przewodnich jest mechanizm rozszerzeń (wtyczek, modułów, etc.). Mechanizm polega na możliwości rozbudowywania produktu o dodatkową funkcjonalność. Po tygodniach żmudnej pracy kolekcjonowania i instalacji wtyczek tak, że ich liczba przekroczyła pierwszą dziesiątkę, już jesteś zadowolony ze zbudowanego środowiska, aż tu nagle dowiadujesz się o nowszej wersji jednej z tak pieczołowicie kolekcjonowanych wtyczek. Produkt (i dowiązane wtyczki) służy Ci do codziennej pracy, więc mając zestawione kompletne środowisko zaczynasz zastanawiać się, czy nowe cechy i poprawki instalowanej wersji wtyczki warte są trudu ponownego zestawiania środowiska. Pytanie nabiera szczególnego znaczenia, kiedy po kilku nieudanych próbach, kolejny raz okaże się, że wtyczka nie działa jak oczekiwano, albo pojawiły się błędy w funkcjonalności, która jest dla Ciebie nieodzowna. Naturalnie pojawia się potrzeba odinstalowania wtyczki. Jeśli taka funkcjonalność istnieje, nie masz się czym martwić, bo odinstalowanie i ponowna instalacja działającej wersji rozwiązuje problem. Stratą jest oczywiście poświęcony czas na kolejne żmudne czynności wokół wtyczki. W niektórych sytuacjach jesteśmy w stanie zaakceptować tę drobną niedogodność. Ale czy zawsze?
Poza już wspomnianą sytuacją, wyobraź sobie kolejną, w której po zestawieniu środowiska (czytaj: zainstalowaniu odpowiednich wtyczek) dowiadujesz się, że pojawia się nowa wersja samego produktu głównego, która poprawia błąd będący powodem Twoich niezliczonych frustracji, bądź po prostu wpływający niekorzystnie na Twoją efektywność. Pojawia się pytanie o sposób instalacji wtyczek. Jeśli ich miejsce składowania to miejsce w strukturze katalogów samego produktu i wtyczki stają się jego integralną częścią (w sensie sposobu jego instalacji na systemie plików) to pojawia się problem ważności posiadania kompletnego środowiska w stosunku do chęci/potrzeb/konieczności (niepotrzebne skreślić) instalacji jego nowej wersji.
Idąc dalej, wyobraź sobie sytuację, w której chciałbyś zweryfikować, czy zbiór wtyczek w ogóle współpracuje z daną wersją produktu i czy ostatecznie podniesienie wersji produktu nie będzie implikowało nieporządanych błędów w tak skrzętnie zestawianym środowisku (nadal nie zapominamy, że dzieje się to wszystko pod presją bieżących zadań, najlepiej dla właściwego zobrazowania sytuacji, wyobraźmy sobie moment zbliżającego się terminu realizacji projektu). Najprawdopodobniej w celu zminimalizowania ryzyka, najpierw zestawiasz kolejne (!) środowisko "na boku" i rozpoczynasz testowanie. Czy jednak nie zrezygnujesz z instalacji i odłożysz ją na bliżej nieokreślony termin? A w ogóle nie szkoda czasu na testy integralności? Nie lepiej byłoby, gdyby wtyczki były umieszczone w jednym miejscu na systemie plików, a produkt jedynie korzystałby z nich bez konieczności kopiowania ich do własnej struktury katalogowej? Czy nie przyjemniej byłoby mieć możliwość włączania i wyłączania wtyczek z jednoczesną możliwością włączania i wyłączania całych ich zestawów? Do tego dołóżmy możliwość umieszczania kompletnych zestawów wtyczek (bez produktu) we współdzielonym miejscu, z którego nowi członkowie zespołu mogliby pobrać je i włączyć do produktu i tym samym "wskoczyć" do projektu bez niepotrzebnie przedłużających się dni wprowadzających? I czy nie byłoby wielce porządane, aby taki produkt dostępny był za darmo? Po prostu, jedynym kosztem wdrożenia produktu byłby Twój czas na zestawienie środowiska (a może nawet nie, jeśli wszystko czeka gotowe). Oczywiście Ty mając pełną kontrolę nad środowiskiem możesz skorzystać z wzorcowego środowiska (produkt + zestaw wtyczek) i jednocześnie mógłbyś również zainstalować własne wtyczki, być może podmieniając istniejące.
Możnaby tak mnożyć możliwe zastosowania produktu udostępniającego mechanizm rozszerzeń i jego zalet (a właściwie zalet oprogramowania modularnego), ale najważniejsze w tym wszystkim to fakt, że ten misternie zbudowany wstęp jak z filmu Hitchocka, kończy się szczęśliwie. Na scenę wchodzi Eclipse RCP z mechanizmem wtyczek opartym o specyfikację OSGi, na bazie którego powstało środowisko programistyczne - Eclipse IDE. Jeśli nie wierzysz, że to wszystko, co napisałem rozwiązuje Eclipse IDE, koniecznie czytaj dalej (przygotuj się tym samym na dawkę dużych emocji okraszonych częstymi 'aha', czy podobnych radosnych okrzyków pełnych szacunku dla własnej niewiedzy ;-)).
Spis treści |
Sposoby upraszczające zarządzanie rozszerzeniami
Wybór katalogu rozszerzeń w Help->Software Updates->Find and Install
Podczas instalacji rozszerzenia (najczęściej wtyczki), zazwyczaj korzystamy z funkcjonalności Eclise IDE, która dostępna jest z menu Help->Software Updates->Find and Install.
Po jej wybraniu, pojawi się pierwszy ekran pomocnika (ang. wizard), który poprowadzi Cię przez proces instalacji nowej wtyczki. Zaraz przed ostateczną instalacją wtyczki istnieje możliwość wybrania położenia katalogu wtyczki.
Wciśnięcie przycisku Change Location... pozwala na wybór innego katalogu niż zaproponowany.
Jest to jedna z możliwości uniezależnienia położenia wtyczki od samego katalogu domowego Eclipse. Pewną niedogodnością jest konieczność każdorazowego przejścia przez proces instalacji i ręcznego wyboru katalogu instalacyjnego wtyczek.
Znakowanie plikiem .eclipseextension
Uproszczeniem procesu zarządzania rozszerzeniami Eclipse jest wykorzystanie mechanizmu .eclipseextension. Polega on na instalacji wtyczek w dowolnym katalogu, który musi zawierać podkatalog eclipse, który z kolei zawiera specjalny plik - znacznik specjalności katalogu - o nazwie .eclipseextension. Właśnie ten plik instruuje Eclipse, że ma do czynienia z katalogiem zawierającym rozszerzenia, m.in. wtyczki. Poza tym plikiem struktura katalogów jest identyczna ze strukturą katalogu instalacyjnego Eclipse. Nie ma znaczenia ile będzie katalogów z rozszerzeniami oraz sama ilość rozszerzeń w pojedyńczym katalogu. Ważne jest, aby struktura katalogów była zachowana, a katalogom eclipse towarzyszył pusty plik .eclipseextension.
Przykładowa struktura katalogu zawierającego rozszerzenia mogłaby wyglądać następująco:
moj_katalog_z_wtyczkami/
eclipse/
.eclipseextension
features/
...tutaj znajdują się cechy...
plugins/
...tutaj znajdują się wtyczki...
Nazwa moj_katalog_z_wtyczkami jest dowolna. Pozostały układ katalog musi odpowiadać układowi katalogów w katalogu domowym Eclipse. Pobierając wersję instalacyjną wtyczki mamy zagwarantowane, że jej rozpakowanie będzie implikowało utworzenie m.in. katalogów features i/lub plugins. Wystarczy wtedy rozpakować wtyczkę do katalogu eclipse, który z kolei zawarty jest w naszym katalogu - moj_katalog_z_wtyczkami.
Po utworzeniu struktury plików opisanej powyżej przystępujemy do dołączenia katalogu do Eclipse. Uruchamiamy Eclipse i wybieramy menu Help->Software Updates->Manage Configuration. Domyślnie jedynym katalogiem w drzewie Eclipse SDK będzie jego własny katalog domowy, który sam w sobie jest również katalogiem rozszerzeń.
Za pomocą polecenia Add an Extension Location istnieje możliwość dodania kolejnych katalogów rozszerzających. Wywołując to polecenie wskazujemy na katalog z rozszerzeniami (w naszym przykładzie byłby to moj_katalog_z_wtyczkami) i zatwierdzamy wciskając przycisk OK. Odwrotna operacja - wyłączenie danego katalogu rozszerzeń - odbywa się za pomocą polecenia Disable, które jedynie wyłączy (ale nie skasuje) katalog. Polecenie wyłączenia pojawi się po wybraniu katalogu rozszerzeń.
Na uwagę zasługuje fakt, że uaktualnienia rozszerzeń z poziomu Eclipse będą zapisywane w samym katalogu wtyczki, a nie Eclipse (co implikuje, że jeśli planujemy wykonywać uaktualnienie wtyczki w ten sposób, musimy pamiętać, aby unikać zawierania wersji wtyczki w nazwie jej katalogu - po uaktualnieniu wtyczki nie będzie to już prawdą).
Dla dociekliwych napiszę, że ścieżki katalogów rozszerzeń przechowywane są przez Eclipse w pliku $ECLIPSE_HOME\configuration\org.eclipse.update\platform.xml.
Katalog skrótów - links
Mając przygotowane katalogi z rozszerzeniami (za pomocą mechanizmu .eclipseextension) możemy przystąpić do skorzystania z kolejnego mechanizmu upraszczającego zarządzanie wtyczkami - katalogu skrótów o nazwie links. Mechanizm polega na umieszczeniu w katalogu links, będącym podkatalogiem katalogu domowego Eclipse, skrótów (odnośników) zawierających wskazanie na katalog z rozszerzeniami.
Instalację wtyczek rozpoczynamy od stworzenia katalogu links, w katalogu domowym Eclipse. Kolejnym krokiem jest stworzenie plików *.link, każdy zawierający jedną linię wskazującą na katalog rozszerzeń poprzez parametr path (UWAGA: stosujemy ukośniki a nie wsteczne ukośniki - inaczej niż w MS Windows), np.
path=C:/apps/eclipse-plugins/moj_katalog_z_wtyczkami
Katalog, wskazany przez path, musi zawierać strukturę katalogów zgodną z mechanizmem .eclipseextension. Nazwa pliku .link nie ma znaczenia, poza samym rozszerzeniem. Podczas uruchomienia Eclipse, każdy katalog wskazany przez skrót w links stanie się automatycznie katalogiem rozszerzeń.
Jedyną możliwą niedogodnością jest utrzymywanie plików .link tak, że podczas instalacji innej wersji Eclipse pozostaje pamiętać o wkopiowaniu katalogu links z potrzebnymi plikami link.
Podsumowanie
Przedstawione mechanizmy Eclipse znacząco upraszczają zarządzanie rozszerzeniami. Mając do dyspozycji możliwość umieszczania plików link w katalogu links tworzymy zestaw plików i wskazanych przez nie katalogów i zarządzamy nimi poprzez system kontroli wersji. Mimo możliwości włączania i wyłączania danych katalogów (a tym samym i rozszerzeń, np. wtyczek) zarządzanie konfiguracją Eclipse za pomocą systemu kontroli wersji pozwala na łagodne wprowadzenie nowych członków do zespołu. Wystarczy poinformować ich o repozytorium katalogów rozszerzeń i umożliwić pracę z wersją Eclipse, na jaką mają ochotę (zakładając, że wspiera ona wersje rozszerzeń). Jeśli w zespole znajdują się osoby, które pieczołowicie uaktualniają Eclipse dnia, w którym pojawia się kolejna wersja, za pomocą mechanizmu katalogu skrótów nie są w żaden sposób ograniczani.
Więcej na ten temat na stronach dokumentacji Eclipse 3.2 Product extensions oraz ciekawe przedstawienie możliwego układu wtyczek na Eclipse - Standardizing plugins across your team.
