Czy warto wejść w jeszcze jeden nowy język: Groovy ?

Uważam, że Java jako platforma ma bardzo wiele do zaoferowania dla twórców systemów informatycznych. Java jako język również sprawdziła (i sprawdza się nadal) się w boju, jednak przyznać trzeba, że czasami brakuje pewnej elastyczności i zakodowanie prostej logiki często wymaga utworzenia wielu (zbyt wielu) linii kodu. Również większość popularnych frameworków dla Javy nakłada spory narzut związany z tworzeniem deskryptorów wdrożenia, tworzeniem pakietów dystrybucyjnych (jar, war, ear) czy częstym przeładowywaniem aplikacji w przypadku zmiany kodu. Narzut ten w przypadku większych systemów nie jest problemem, gdyż w zamian otrzymujemy konfigurowalne, stabilne, bezpieczne i rozwojowe środowisko, natomiast przy mniejszych modułach jest szczególnie mocno i negatywnie odczuwalny. I tu pojawia się Groovy – skryptowy język dla platformy Java, bardzo podobny składnią do języka Java – rozszerzony jednak o kilka istotnych elementów takich :
• zmienne z określonym lub nieokreślonym typem
• pełnym autoboxing’iem
• wsparciem dla tablic, list, map, stosów i innych struktur z poziomu języka – oczywiście z wykorzystaniem biblioteki kolekcji Javy (przy zunifikowaniu metod do ich obsługi np. każdy obiekt, który posiada jakąś formę listy posiada metodę size())
• domknięcia (closures)
• obsługę wieloliniowych stringów, wyrażeń regularnych, szablonów na poziomie stringów (jak w php)
• rozszerzenie wielu często wykorzystywanych bibliotek Javy i dostosowanie ich do
• strukturę „budowniczych” (builders) – do tworzenia struktur takich jak xml, html, formularzy swing i innych
i wielu innych opcji.

Wszystko razem sprawia wrażenie, jak gdyby język ten powstał w wyniku zebrania i rozwiązania wielu niewygodnych cech Javy, jednocześnie nie odchodząc od znanej i czytelnej składni (dla przykładu, nie ujmując mocy, Ruby to zupełnie inny język).

Poniżej małe zestawienie.

Problemy, które Groovy może pomóc rozwiązać:
• duża ilość kodu do zakodowania prostej logiki
• konieczność przeładowywania całej aplikacji w przypadku zmiany kodu
• narzut związany ze stworzeniem wersji dystrybucyjnej
• konieczność własnej obsługi (zakodowania) ewentualnych opcji konfiguracji

Korzyści z zastosowania Groovy:
• mniej kodu aby osiągnąć ten sam efekt w Javie
o część z najczęściej przewijających się zadań programistycznych jest świetnie ułatwiona w Groovy (praca z SQL, xml, swing itp.).
• pełna kompatybilność z Java
• bardzo prosta integracja z systemami na platformie Java
• minimalny wysiłek dla programisty pracującego z Javą aby korzystać z Groomy
• możliwość uelatycznienia (dodania skryptowania) do dużych systemów w Javie
• brak konieczności przeładowywania modułów stworzonych w Groovy

Wady Groovy:
• wydajność (ale z wersji na wersję jest coraz lepiej – czekamy na 1.6 która ma mieć znaczące ulepszenia w kwestii wydajności)

Możliwości zastosowania:
• dodanie możliwości oskryptowania istniejących systemów zbudowanych w Javie
• tworzenie skryptów operujących na bazach danych, dokumentach xml, systemie plików
• tworzenie często zmieniających elementów systemów
• tworzenie prototypów aplikacji
• generowanie zaawansowanych raportów
• tworzenie aplikacji webowych (nie wspominam o Grails)
• oraz nieskończenie wiele innych, jak w przypadku każdego innego języka programowania (z tym szczegółem, że możemy zaimportować do skryptu Groovy każdą bibliotekę skompilowaną w Javie)

tworzenie wersji dystrybucyjnej aplikacji w pliku jar

Gdy zachodzi potrzeba stworzenia wersji dystrybucyjnej modułu w postaci pliku jar wraz ze wszystkimi zależnościami (wykorzystywanymi bibliotekami jar) możemy posłużyć się maven2 i pluginem maven-assembly-plugin. Dodatkowo można określić klasę uruchomienia która zostanie wskazana w pliku manifest.mf.

W pliku pom.xml możemy umieścić:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>com._3e.projekt.MainClass</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
Aby zbudować pakiet z zależnościami należy uruchomić mavena z celem assembly:assembly:
Mvn assembly:assembly

Więcej o tym pluginie na stronie: http://maven.apache.org/plugins/maven-assembly-plugin/howto.html .

korzyści ze stosowania ciągłej integracji

Postanowiłem opisać kilka korzyści jakie daje wdrożenie i stosowanie techniki ciągłej integracji:

• integrowanie pracy wszystkich developerow na bieżąco od momentu rozpoczęcia projektu
  - dzięki temu unikamy sytuacji gdy dwie lub więcej osób tworzy nie pasujące do siebie moduły i później trzeba poświecić wiele czasu na dodatkową integrację
  
• pewność, ze proces budowania projektu jest w pełni automatyczny i niezależny od srodowiska developerów
  
• pełna kontrola nad zależnościami (np. wymaganymi bibliotekami) dla modułów w projekcie
  
• wyłapywanie problemów na styku modułów na wczesnym etapie prac
  
• informacja dla kierownika projektu o tym, że skomitowana wersja jakiegoś modułu nie kompiluje się
  
• możliwość wglądu w wyniki automatycznych testów i automatycznych raportów dla wszystkich członków projektu bez konieczności ich uruchamiania
  
• możliwość wykonania dodatkowych operacji na artefaktach wygenerowanych podczas budowania systemu
  - np. wgrania najnowszej wersji dystrybucyjnej modułu na serwer ftp, z którego testerzy mogą zawsze ściągnąć najnowsze wersje
  
• pewność że nie będzie problemów ze zbudowaniem całego projektu u nowego developera lub w innym środowisku
  
• możliwość wykonywania dodatkowych testów integracyjnych w osobnym środowisku (nie u developerów)
  
• możliwość odciążenia maszyn developerów poprzez budowanie i umieszczanie w repozytorium artefaktów tworzonych przez innych developerów