03 lutego 2010

De gustibus non est disputandum - Eclipse Groovy 2.0.0 dostępny

Wszystko zaczęło się od artykułu Groovy 1.7, Grails 1.2 and Groovy Eclipse 2.0 Updates Include Dependency Management,Language Support. Już miałem lekturę zmian w Groovy 1.7 i Grails 1.2 za sobą (nota bene, 1 lutego pojawiło się wydanie 1.2.1), więc pewnie nie dałbym się namówić na jego przeczytanie, ale dodatek w postaci Groovy Eclipse w temacie sprowokował mnie. Szczęśliwie artykuł, a raczej zajawka nowych wydań projektów, nie jest długi, więc wystarczył kwadrans i było po krzyku.

Podobają mi się takie dywagacje nad kodem, co można, a co nie i dlaczego. W tym artykuliku dowiedziałem się o java.util.concurrent.atomic.AtomicInteger (wciąż lektura zmian w Java SE 6 przede mną i tylko tyle wiem, ile się przydaje po drodze - pewnie niejedno przysłowiowe koło odkryłem w międzyczasie) i kolejny raz o Grape. W przypadku Grape, autor ciekawie przedstawia zalety dekorowania importów z adnotacjami, które zwykle trafiają do zewnętrznych plików w Maven czy Ant. Ciekaw jestem, ilu z Was podziela zdanie o "This in turn triggers the download of the dependency and makes your code's build more self-documenting." Mam wrażenie, że autor przekonuje, że użycie wszystkiego, co związane z klasą, bezpośrednio w niej, to dobra rzecz. Moje skromne doświadczenie programistyczne nie pozwala mi dostrzec tych zalet, bo jakkolwiek korzystam z adnotacji Java EE 5+, to tylko i wyłącznie w fazie prototypowania czy wczesnego rozwoju aplikacji. Później, preferuję podejście czysty technologicznie kod źródłowy ze wszelkimi dodatkami technologicznymi w postaci plików XML i to jeszcze w osobnych modułach projektowych. Stawiając sprawę jasno, adnotacje w kodzie dobre, ale docelowo nalegałbym, aby się ich stamtąd pozbyć i wynieść na zewnątrz, np. do plików XML.

O Grails 1.2 jedynie się wspomina, więc nie ma co liczyć na chociażby taki przekrój wiedzy, jak to ma miejsce w przypadku Groovy 1.7. Podobnie z Groovy Eclipse. Zdaje się, że autorowi bliżej do Groovy niż do pozostałych produktów i dodał je, bo...kazano (?). Początek (o Groovy) był świetny z końcówką (o Grails i Eclipse Groovy) do kosza. Można skończyć czytać na akapicie o Grails 1.2.

Gdyby ktoś mogł mi jeszcze wyjaśnić, co autor zamierzał wyrazić przez dwukrotne użycie angielskiego słowa 'sport' w artykule, byłoby cacy. Kompletnie nie mogę docieć, co to słowo znaczy w tym artykule.

Po artykule, zabrałem się za instalację wtyczki Eclipse Groovy. Instalacja zabrała niespełna kilka minut. Wystarczyło pobrać aktualną wersję Eclipse IDE for Java EE Developers 3.5 SR1 (3.6m4 nie działała) i dopisać http://dist.springsource.org/release/GRECLIPSE/e3.5/ jako stronę z aktualizacjami Eclipse Groovy (zainteresowani skrinkastem nt. tej instalacji, proszeni są o komentarz do wpisu). Po instalacji, chwila na restart Eclipse i miałem go uzbrojonego o wtyczkę Eclipse Groovy 2.0.0.

Przejrzałem kilka nowości, które oferuje i wybrałem najważniejsze z mojego punktu widzenia (pisanie dokumentów typu "New and Noteworthy" to wielka odpowiedzialność, bo ma tę wadę/zaletę, że "rozleniwia" potencjalnych użytkowników do badania tylko tych funkcjonalności, które zostały przedstawione w dokumencie - wiele ciekawostek może zostać nieodkrytych do czasu przypadkowego trafienia podczas pracy, a wciąż mogą być interesujące dla szerokiej publiczności):

- z Groovy-Eclipse 2.0.0M1 New and Noteworthy:

Incremental compilation, co zgodnie z nazwą sprowadza się do kompilacji jedynie tych elementów projektu, które zostały zmienione bez względu na język, w jakim zostały napisane - Java czy Groovy. Innymi słowy, ma być szybciej, dzięki integracji kompilatora Eclipse JDT i Groovy.

JUnit Monospace font do wyświetlania wyników uruchomienia testów z Spock Framework. Nigdy nie używałem go wcześniej, a jedynie słyszałem wzmianki o nim, więc teraz chociażby z ciekawości, ile będzie mnie kosztowało uruchomienie go w Eclipse i docenienie zmian we wtyczce Eclipse Groovy znajdę czas dla niego.

Wyłączanie Groovy Script z kompilacji przy budowaniu/uruchamianiu projektu. Wystarczy wybrać opcję Build Path > Exclude z menu kontekstowego na wybranym skrypcie groovy.

Breakpoints and debugging - mamy możliwość ustawiania miejsc zatrzymania (ang. breakpoints) debugera i podejrzenia stanu zmiennych skryptu/aplikacji napisanej w Groovy.

Runtime evaluation of Groovy code - wyliczanie wyniku uruchomienia wycinków kodu Groovy.

- z Groovy-Eclipse 2.0.0M2 New and Noteworthy:

Refactoring Support - zmieniamy zmienną/metodę/klasę w Javie i zmiany propagują się do kodu Groovy, i na odwrót.

Task Tags - znamy i używamy - TODO, FIXME i XXX w kodzie Groovy rozpoznawane są dokładnie jak w Javie.

Wszystkie ze zmian opisane są dokładniej na blogu autora wtyczki Contraptions for programming, więc spragnieni wiedzy (a tylko tacy tutaj zaglądają :)) mogą pozwolić sobie na więcej...wiedzy.

- z Groovy-Eclipse 2.0.0RC1 New and Noteworthy:

Jars from .groovy/lib directory added to classpath - dodajemy wybrane jary do katalogu ~/.groovy/lib i automatycznie trafiają do ścieżki klas (CLASSPATH) naszego projektu. Niekoniecznie potrzebne biorąc pod uwagę możliwość skorzystania z Apache Maven 2, ale...nie wszyscy z niego korzystają (= straceńcy :))

To tylko wybrane usprawnienia we wtyczce Eclipse Groovy i zostały przeze mnie namaszczone mianem tych ważniejszych, co niekoniecznie musi spełniać kryteria Waszej ważności. Szczegółów należy szukać bezpośrednio u źródła - na stronie wtyczki Eclipse Groovy.

Interesujący jest fakt, że mamy publicznie dostępną wersję finalną wtyczki, a w JIRA jest 1 otwarte zgłoszenie na poziomie Major. Widać JIRA swoje, a wtyczka swoje. I tak, głównymi i jedynymi opiniodawcami są sami użytkownicy i bez względu na ilość włożonej pracy nawet największe dzieło może nie doczekać się właściwego poszanowania. W końcu piękno to kwestia gustu, a o nim się nie dyskutuje...De gustibus non est disputandum, albo Beauty is in the eye of the beholder. Wspaniale pasuje jako podsumowanie dyskusji nt. assert w komentarzach do Niemy film(ik) na weekend - Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2. Dzięki Wujek za "uzyles asercji bo chciales i tyle." Właśnie! ;-)