Gradle¶

Słowem wstępu¶

Gradle to build tool który wyrósł na kilku sprawdzonych technologiach:

• Ant - z którego korzystamy w tej chwili - to narzędzie świetnie nadaje się do prostych operacji na systemie plików, paczkowania, etc
• Maven - narzędzie wyrosłe na Ancie, wprowadziło koncepcję projektu, jako czegoś więcej niż tylko pliki w katalogach - teraz na projekt składa się kod, zależności (czyli biblioteki zewnętrzne) oraz zadania (już nie targety w stylu make'a, jak w Ancie, a zadania - czyli bardziej skomplikowane pomysły). Powyższe zdanie to rzecz jasna uproszczenie. Dodatkowo Maven wprowadził strukturę plików w projekcie która doskonale pasuje do Test Driven Development (wyraźny podział na produkt i testy, każda z części składa się z kodu i zasobów - czyli konfiguracji, danych testowych, etc - wszystkeigo czego nie kompilujemy). Chyba największy plus Mavena - repozytoria bibliotek, np http://mvnrepository.com/ . Są to serwery, które przechowywują i udostępniają zewnętrzne biblioteki w różnych wersjach i pozwalają na ich pobranie, przez co we własnym repozytorium nie trzeba trzymać cudzego kodu (i zawsze ma się pewność, że biblioteki są w tej wersji której potrzebujemy)
• Groovy - język programowania wyrosły z Javy, kompilowany do tego samego bytecode'u (więc można korzystać z klas w nim napisanych w Javie, Scali, etc i na odwrót). Jest to IMO najwygodniejszy język dynamiczny na JVM (dynamiczny znaczy, że klasy mogą się zmieniać podczas wykonania programu, np możemy dodawać metody, kompilować klasy, etc). Pozwala na bardzo wygodne tworzenie DSLi (Domain Specific Language).

Gradle ma wbudowany ant builder, który pozwala opisać wszystko co da się opisać w Ancie przy pomocy Gradle, oraz importować Antowe pliki XML do buildów Gradle. Z Mavena czerpie strukturę katalogów oraz system rozwiązywania zależności (komunikacji z repozytoriami bibliotek; udostępnia też system Ivy do tego samego, ale nigdy go nie używałem). Same buildy to de facto skrypty Groovy, ale to nie znaczy, że trzeba znać Groovy żeby z tego korzystać. W zamian dostajemy pliki build w których możemy używać konstrukcji programistycznych w stylu for, while, kolekcji w stylu list i map, etc - build przestaje być sztywny, a zaczyna faktycznie przypominać zestaw poleceń.

Użycie¶

Przygotowanie repozytorium¶

Po sklonowaniu repo nie trzeba robić NIC. Gradle automatycznie (przy pierwszym uruchomieniu) potworzy katalogi, których brakuje, dociągnie biblioteki, etc, etc.
Przypominam, że w tym momencie Gradle jest używane tylko na niektórych gałęziach.

user@host:X$ git clone git@nlp.pwr.wroc.pl:liner2
user@host:X$ cd liner2
user@host:X/liner2$ git checkout liner25_dev_gradle

Wybór gradle¶

JEŚLI CZYTASZ TO PO RAZ PIERWSZY, TO ZWRÓĆ UWAGĘ NA TEN AKAPIT!

Do repozytorium dołączyłem wrapper dla gradle - to mały skrypt, który automatycznie dociąga samo gradle, jeśli go brakuje. Jest stworzony tak, żeby działać identycznie jak lokalna dystrybucja.
Jeśli ktoś ma zainstalowane gradle lokalnie (co osobiście polecam, choć nie jest to wymagane), to niech używa lokalnego programu (zapewne będzie nazywać się "gradle", po prostu). Jeśli nie mamy lokalnej dystrybucji, to używamy wrappera: skryptu "gradlew" na unixach i podobnych (na Macach też), "gradlew.bat" na windowsie.

W dalszej części dokumentu przykłady będę podawał tak, jakbyśmy mieli lokalną instalację, ale poniżej przedstawiony jest przykład jak ta sama linia będzie wyglądać u różnych osób:

user@host:X/liner2$ gradle build            # z lokalną instalacją pod nazwą "gradle" 
user@host:X/liner2$ ./gradlew build         # z użyciem wrappera na linuksie i macu
C:\X\liner2> ./gradlew.bat build            # z użyciem wrappera na windowsie

WIP (work in progress)