Splatch’s devblog

Odyseja kosmiczna 2007

Zastanawiałem się kiedyś skąd twórcy Eclipse biorą nazwy dla kolejnych wydań. O ile samo Callisto ma wiele znaczeń (mitologiczna kochanka Zeusa, postać filmowa, księżyc Jowisza, komiks, model samochodu czy też kapela) o tyle w parze z Europą, najnowszym wydaniem kwestia staje się jasna. Bez wątpienia chodzi tu o księżyce Jowisza. Troszkę zadziwiający jest fakt, że dobór nazw nie zbiega się z kolejnością księżyców (największy jest Ganimedes, następnie Callisto, Io i na samym końcu Europa). No, może dywagacje na temat nazw i pochodzenia pozostawimy, chociaż “astronomiczny” akcent Eclipse nas na długo nie opuści, bowiem w notce tej zamierzam przedstawić wcześniej wymienione, najświeższe, wydanie – Europę.

Historia wydań

Były czasy, kiedy skompletowanie sobie wszystkich potrzebnych pluginów do Eclipse wymagało wiele wysiłku. A to stąd pobrać GMF, stąd JET, do tamtego jeszcze coś i tak przez pół dnia. Każdy projekt miał własny update site, który zawierał mniej czy też bardziej stabilne wersje. Wykorzystanie funkcjonalności “select required” ograniczało się tylko i wyłącznie do tego, że po kliknięciu w przycisk po prostu klęliśmy, że nie działa i trzeba szukać kolejnego update site’a. Problem ten definitywnie rozwiązało Callisto. Na jego podstawie zostały zasadniczo stworzone trzy “dystrybucje”. Pierwsza dla programistów J2SE, druga dla osób zajmujących się Eclipse od podszewki oraz trzecia dla programistów C/C++. Dodatkowo korzystając z istniejących pakietów można przy użyciu update managera stworzyć pakiet dostosowany do własnych potrzeb.
Europa jak wcześniej wspominałem jest znacznie większa, ponieważ zawiera aż 21 projektów podczas gdy na Callisto składało się ich “tylko” 10. Ponadto nowe wydanie zawiera dodatkową dystrybucję przeznaczoną do pracy z JEE. Myślę, że wielkość tego wydania jest znakomitym dowodem popularności Eclipse jak i prężności developerów.
Jako ciekawostkę dodam kilka liczb, na które trafiłem dzięki notce na blogu Iana Skerretta
Wartość 16 projektów spośród 21, notowanych na Ohloh.net to, uwaga, 305 991 384 dolarów (słownie trzysta pięć milionów, dziewięćset dziewięćdziesiąt jeden tysięcy, trzysta osiemdziesiąt cztery dolary). Jest to wartość około 19 339 912 linii kodu rozwijanych ostatnimi czasy przez 312 osób!

Dostępne dystrybucje

Java. Dystrybucja przeznaczona do pracy z J2SE. Sercem platformy jest JDT (Java Development Tools), czyli “standardowy” edytor rozbudowany o nowe opcje. Zawiera część WTP (edycja XML, XSD itp).

JEE.Wersja przeznaczona do pracy z JEE jak i “starym” J2EE. Zawiera WTP 2.0 (Web Tools Platform) oraz JST (J2EE Standard Tools) – wsparcie dla edycji JSF, JSP itp. Zapewnia wsparcie dla JPA. Jest to najbardziej “wypasiona” dystrybucja, ponieważ zawiera większość projektów wydanych w ramach Europy.

Classic. Dystrybucja będąca miksem wersji Java i RCP. Zawiera źródła projektów, dokumentację nie tylko dla użytkowników ale i dla developerów. Przeznaczona do tworzenia aplikacji w oparciu o Eclipse RCP jak i rozszerzeń samej platformy.

C/C++. Kompletne środowisko dla programistów piszących w językach C/C++ oparte na Eclipse. Całość okrojona do CDT/CVS/RCP. Brak źródeł jakichkolwiek pluginów, wsparcia dla czegoś niezwiązanego z C/C++. Tylko ta dystrybucja nie jest zintegrowana z Mylynem.

RCP. Pochodna wersji Classic okrojona tylko o ilość źródeł (nie zawiera źródeł JDT, CVS)

Wszystkie wymienione wyżej dystrybucje można oczywiście modyfikować przy pomocy standardowej aktualizacji. Są to tylko pre definiowane wersje, które mają na celu ograniczenie do minimum ilości pracy potrzebnej do skompletowania środowiska. Przy użyciu każdej z tych dystrybucji możemy praktycznie od razu zacząć pracę. Drobnym wyjątkiem jest tutaj C++, ale o tym dalej..

Najciekawsze rozwiązania

Mylyn 2.0

Zdaje się, że Mylyn stał się perełką całej platformy, aż dziw bierze, że tak proste narzędzie powstało “dopiero” teraz. Piszę dopiero, ponieważ rozszerzenie to ma już kilka lat, jednak dopiero niedawno pojawił się “szum medialny” wokół niego. Pierwsze screencasty, prezentacje i w rezultacie gwałtowny wzrost popularności rozszerzenia. Jest to jeden z najwyżej ocenianych i najbardziej aktywnych dodatków do platformy na Eclipse Plugins Central.

Czym jest Mylyn? Mylyn to narzędzie integrujące Eclipse z repozytoriami zadań takimi jak JIRA, Trac, Bugzilla i tak dalej. Dane, które pobierze z repozytorium zapisuje lokalnie i co jakiś czas synchronizuje. W ten sposób w Eclipse możemy przeglądać i monitorować przebieg prac nad danym zadaniem. Co więcej, jeśli do zadania dołączymy kontekst (załącznik). W odpowiedniej perspektywie możemy przeglądać listę zadań (zapytań). Na liście tej są oznaczone zadania, które są zakończone, otwarte, aktywne czy też jeszcze nie przeczytane.

Mylyna można stosunkowo łatwo rozszerzać. Coraz więcej dostawców integruje swoje narzędzia z Mylynem dzieki czemu kontekst może obejmować nie tylko Package explolera ale również widoki tj outline itp. Sam nawet próbowałem troszkę powalczyć z tym rozszerzaniem, niestety z racji na to, że zdecydowałem się na próbę Mylyn-PDT poległem. Przykładowe implementacje są bardzo proste. Patrząc na klasy dostarczone razem z Mylynem modyfikujące zawartość różnych widoków można stwierdzić, że to w sumie nie jest trudne. No, ale w praktyce bywa inaczej.
O ile braki w komentarzach tego pierwszego można uzupełnić odwiedzając wiki o tyle z PDT tak łatwo już nie jest. Wszędzie jakieś braki w komentarzach, trafiają się fragmenty, gdzie jest publiczny interfejs a nie ma w nim nawet linijki komentarzy. Wydaje mi się, że takie sytuacje raczej nie sprzyjają PDT Summer Camp. No, ale do PDT 1.0 mamy jeszcze troszkę czasu, więc być może coś w tym projekcie się poprawi….

Na koniec dodam jeszcze dwa screenshoty pokazujące, jak głęboko Mylyn jest zintegrowany z edytorem tekstu. Może on “zawijać” te fragmenty kodu, które nie mają nic wspólnego z zadaniem pozostawiając tylko te, które są zawarte w kontekście. Świetna sprawa, gdy ma się klasy, które mają kilkaset linii kodu i odnalezienie w nich metody to wyłapywanie nazwy w outline. ;)

Mylyn bez wątpienia jest rozszerzeniem godnym uwagi. Jeśli w pracy macie do czynienia ze sporym stosem kodu w którym często na zmianę łatacie różne błędy to bardzo ułatwi on Wam życie. Wydaje mi się, że na tą chwilę żadne środowisko nie posiada tak dobrej integracji z repozytoriami zadań.
Osobiście jest to dla mnie najlepsza rzecz jaka weszła do Europy.

Eclipse RCP 3.3/JFace

. W nowej wersji jest kilka usprawnień. Najbardziej istotnym jest nowy sposób na zarządzanie widoków. Wcześniej widoki mogły wysuwać się tylko z jednej strony. Nie było czegoś takiego jak “fast view” na modłę Visual Studio, gdzie zakładki chowały się bądź pokazywały gdy najeżdżało się na nie myszą. Połowicznym sposobem na ten problem była minimalizacja/maksymalizacja widoku.
Połowicznym, ponieważ pokazanie konsoli powodowało ponowne pokazanie wszystkich widoków. Od wersji 3.3 możemy wybierać który widok ma się pokazać dynamicznie, minimalizować całe “grupy” widoków. Jak dla mnie bomba, dzięki temu mogę napisać sobie na szybko coś w edytorze mając widoczny tylko outline i dynamicznie wysuwaną konsolę, bez niepotrzebnych mi widoków. Dodam, że widoki zachowują się tak samo w RCP jak również IDE. Dodając do tego również Eclipse Packaging Project [nie jest częścią Europy] w połączeniu z PDE zyskujemy środowisko do tworzenia aplikacji okienkowych od A (kodowanie) do Z (tworzenie instalatorów).

JDT 3.3

Wraz z ewolucją platformy postępuje ewolucja JDT, które jest pokazem możliwości Eclipse. Wiele osób kojarzy JDT z Eclipse, chociaż tak nie jest JDT to tylko przykładowa (chociaż bardzo dobra) implementacja środowiska w oparciu o Eclipse. Nowa wersja dodaje kilka usprawnień.
1. Save actions. W chwili gdy zapisujemy edytowany plik JDT może wykonać różne operacje. Od usunięcia zbędnych importów i dodania adnotacji @Override/@Deprecated tam gdzie trzeba przez posortowanie pól, metod bo nazwach oraz formatowanie kodu po rzecz tak błahą jak usunięcie zbędnych spacji z końca linii. Nigdy więcej wciskania Ctrl+Shift+O, Ctrl+Shift+F, zrobi to za Ciebie edytor! Sam powoli zaczynam walczyć ze sobą by nie wciskać pierwszego z tych skrótów przed zapisaniem pliku.
2. Spelling. Sprawdzanie pisowni w edytorze? Czemu nie, w końcu komentarze powinny być pisane językiem zrozumiałym dla wszystkich, nie tylko dla autora. ;) Opcja ta pozwoli wyłapać literówki, nie sprawdzi jednak czy zdanie jest poprawne pod kontem składni czy gramatyki. Tak czy owak lepiej poprawić błąd w komentarzu zanim kod się wrzuci do repozytorium niż po fakcie, gdy ktoś zwróci nam uwagę. Błędy składni JDT podkreśla miłym dla oka żółtym kolorem. Niestety nie udało mi się poprawnie skonfigurować słownika dla języka polskiego. Wersja z Open Office/kurnik.pl jest zapisana w troszkę innym formacie niż wymaga plugin, co powoduje problemy.
3. Zmienione zachowanie skrótu CTRL+F11. Domyślnie skrót ten uruchamia ostatnią konfigurację dla aktywnego pliku. Prawdę powiedziawszy doprowadzało mnie to do szewskiej pasji i zmieniłem to na standardowe zachowanie tak by działało tak jak wcześniej, czyli ostatnia uruchomiona konfiguracja.
4. Podpowiadanie w blokach catch. Standardowo trzeba było tam wpisywać z “palca” nazwę wyjątku posiłkując się inspectorem. W wersji 3.3 do wyboru mamy tylko te wyjątki, które wylecą z danego bloku.

Drobnych zmian jest więcej, nie mniej ich opis pomijam z racji na to, że nie ma to być changelog a tylko informacja o tym, co się stało. Tak więc z mniej istotnych – skrót do nawigacji po widokach (CTRL+F3) bądź usprawnione podpowiadanie w edytorach PDE bądź “rename in line”, czyli bezpośredni podgląd zmian nazwy elementu bez konieczności uruchamiania kreatora.

Web Tools 2.0

Projekt ten obejmuje wiele subprojektów, których ilość jest dość spora. Web Standard Tools to nic innego jak komplet edytorów do edycji plików xml, xsd, html, css, js, wsdl i tak dalej. Zmian w stosunku do poprzednich wersji nie odnotowałem [czyt. nie zauważyłem].
Screenshoty z wersji 1.5: XML 1, XML 2, XSD 1, XSD 2, XSD 3.

J2EE Standard Tools

Jednym słowem: kobyła. Jeśli jest coś w J2EE/JEE czego nie można edytować przy użyciu tego narzędzia to musi to być chyba jakaś spora nowość. ;) Na uwagę zasługuje poprawiony edytor graficzny, który sprawuje się całkiem dobrze nawet przy nie do końca poprawnej strukturze pliku. Potrafi on sobie poradzić [czyt. ominąć] skryplety i bardzo ładnie zaznacza elementy zawarte w tagach jsp – niezależnie od tego czy jest to logic:empty (struts) czy też c:if (jstl). Edytor graficzny jest połączony z edytorem tekstowym. Po kliknięciu na jakiś komponent w edytorze graficznym w edytorze tekstowym zostanie on zaznaczony. Problemem z JST jest niestety jego “ręczna” konfiguracja. Nie ma nigdzie opcji pozwalającej na zmianę katalogu zawierającego pliki przeznaczone do spakowania w WAR. Przy korzystaniu z Mavena trzeba edytować plik konfiguracyjny pluginu!
Oczywiście sam plugin ma bardzo wiele opcji – można przy jego pomocy tworzyć aplikacje w oparciu o EJB2.1/3 a także z użyciem JPA, niestety nie miałem do tej pory okazji do wykorzystania tegoż, stąd rezygnuję z opisu.

CDT 4.0

Nie jestem programistą C/C++ i gdyby nie studia to prawdopodobnie uniknąłbym konieczności poznawania CDT. No, ale okazja się nadarzyła, i prawdę powiedziawszy nie mam powodów by żałować. Do C++ jest wiele środowisk. Jest komercyjne (Visual C++) i niekomercyjne (Visual C++ Express Edition) jak i DevCpp. Są zapewne też inne, mniej bądź bardziej popularne. Mi się nie spodobało ani jedno ani drugie, być może z racji na przyzwyczajenie do Eclipse, jakkolwiek samo CDT również ustępuje JDT, chociaż patrząc na DevCpp oferuje (tu piszę bardzo subiektywnie) większą funkcjonalność.
Edytor sprawuje się bardzo dobrze, podpowiada tam gdzie trzeba to co trzeba. Mamy do dyspozycji gro opcji – od formatowania kodu przez dyrektywy kompilatora, dodatkowe biblioteki i tak dalej. Opcji jest multum i ja jako nowicjusz nie miałem okazji by wykorzystać wszystkie.
Bolączką jest niestety brak dorzucania dyrektyw #include tak jak to ma miejsce w przypadku JDT, gdzie wybieramy klasę i import już jest. Trzeba się też przyzwyczaić do tego, że błędy zostaną podkreślone dopiero po próbie kompilacji, ponieważ ta wtyczka bazuje na tym, co zwróci kompilator w czasie pracy, nie ma możliwości weryfikacji kodu just-in-time. Jest za to debugger oparty o gdb. Działa on bardzo dobrze i nie ma problemów z jego użyciem. Nie odbiega on wiele od tego, co ma Java.
Troszkę Brakuje mi czegoś na modłę “quick fix”, gdzie wybieramy proponowane rozwiązanie dla danego problemu. Zapewne wynika to w dużej mierze z tego, że C++ jest językiem bardziej złożonym (mniej doskonałym?) niż Java i samo zaimplementowanie mechanizmu propozycji eliminacji błędów byłoby bardzo kłopotliwe. Kto wie, być może w przyszłych wersjach będziemy mogli zobaczyć więcej. Wierzę, że developerzy pracujący nad tym pluginem mają ambicje by tworzyć najlepsze środowisko do C++, które będzie miało funkcjonalność taką samą bądź jeszcze lepszą niż JDT. Samo CDT 4.0 dosyć szybko stanęło w szranki z WTP o pierwsze miejsce pod względem ilości pobrań. Przegrało po kilku dniach walki. Taki stan rzeczy (CDT wciąż jest drugie) może świadczyć o sporym zainteresowaniu takim środowiskiem w społeczności programistów C/C++. Trzymam kciuki za rozwój tego projektu, ponieważ z nim pisanie w C++ stało się dla mnie przyjemnością! :)