Spotkanie Poznan JUG: Gradle – Software delivery automation tool that makes the impossible possible, the possible easy and the easy elegant [28.04.2015]

[Łukasz Stachowiak]

Zapraszamy wszystkich na kolejne spotkanie Poznan JUG, ktore odbedzie sie we wtorek (28.04.2015) o godzinie 18:00 w siedzibie Allegro (ul. Grunwaldzka 182, biurowiec Pixel) sala 01/02. Bedziemy mieli okazje wysluchac prezentacji Marcina Erdmanna, ktory przedstawi temat „Gradle – Software delivery automation tool that makes the impossible possible, the possible easy and the easy elegant [28.04.2015]” Osoby ktore chca uczestniczyc w spotkaniu powinny zarejestrowac sie tutaj.

O czym bedzie mowa? Poniżej kilka slow o temacie:

Podczas tej prezentacji dowiecie sie co to jest Gradle i dlaczego warto zainwestowac swoj czas w nauke tego narzedzia. Powiem dlaczego warto zmigrowac Wasze projekty i jak to zrobic. Opowiem o tym jaka filozofia przyswieca Gradle i jakie sa jego najciekawsze i najbardziej uzyteczne funkcjonalnosci. Pokaze zaawansowane mozliwosci rozwiazywania zaleznosci i wyjasnie dlaczego ta funkcjonalnosc jest tak gleboko zakorzeniona w to narzedzie. Porozmawiamy o tym jakie problemy Gradle moze dla Was rozwiazac na dzien dzisiejszy i w jakim kierunku zmierza. Bedzie o tym co to sa pluginy i o tym z jakimi technologiami pozwalaja sie zintegrowac. Wytlumacze co moze Wam dac spolecznosc, ktora sie wytworzyla wokol tego narzedzia i o tym co oferuje Gradleware, firma, ktora stoi za rozwojem Gradle. Powiem tez o tym dlaczego uwazamy, ze Gralde to na chwile obecna najlepszy build system ogolnego zastosowania jaki istnieje.

Marcin Erdmann currently based in London and part of the Gradleware crew, loves Open Source Software and has a strong need to give back to the community whenever possible. That’s why he’s proud to be the current project lead of Geb, a Groovy Browser automation library. In the past he contributed to many open source projects in the Groovy ecosystem and he enjoys going to conferences both as an attendee and a speaker. That’s where you will find him with a pint of good beer in hand engaged in lengthy discussions on how to make software development process and quality better.

ZAREJESTRUJ SIĘ

ps. brak polskich znakow spowodowany usterka w wordpress – pracujemy nad tym 

[Marcin Erdmann]

Hej,

Jeszcze raz dzieki wszystkim za przybycie, mam nadzieje, ze udalo mi sie zainteresowac Was Gradle i moze przekazac jakas nowa wiedze tym, ktorzy juz go uzwaja.

Dawid Weiss zadal pare pytan po prezentacji. Odpowiem tutaj, bo nie wiem czy jego politechniczny adres nadal dziala, a nie mam zadnego innego.

Bylo pytanie o to gdzie mozna sie zapoznac z kodem plugina eclipsowego, ktory bedzie w przyszlosci pozwalal sie zintegrowac z Gradle. Repo jest tutaj: https://github.com/eclipse/buildship.

Bylo tez pytanie o to czy mozna sobie tak skonfigurowac projekt aby artifact cache znajdowal sie w katalogu projektu i odpowiedzialem, ze nie. Po przemysleniu sprawy okazuje sie, ze nie byla to do konca poprawna odpowiedz. Lokalizacje katalogu domowego Gradle mozna skonigurowac za pomoca zmiennych srodowiskowych, wlasnosci systemowej albo przelacznika z linii polecen (http://mrhaki.blogspot.com/2010/09/gradle-goodness-changing-gradle-user.html). Najprostszym rozwiazaniem byloby chyba zawarcie tej konfiguracji w zmodyfikowanym skypcie Gradle Wrappera. Nie wiem czy to jest super praktyka, ale da sie to zrobic.

Pozdrawiam

Marcin

--
Otrzymujesz tę wiadomość, bo subskrybujesz grupę „Poznań Java User Group” w Grupach dyskusyjnych Google.
Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na jug-poznan+...@googlegroups.com.
Aby opublikować wpis w tej grupie, wyślij e-maila na jug-p...@googlegroups.com.
Otwórz tę grupę na http://groups.google.com/group/jug-poznan.
Więcej opcji znajdziesz na https://groups.google.com/d/optout.

[Dawid Weiss]

> Dawid Weiss zadal pare pytan po prezentacji. Odpowiem tutaj, bo nie wiem czy jego politechniczny adres nadal dziala, a nie mam zadnego innego.

Działa, działa, ale odpowiedź publiczna jest chyba lepsza.

> Najprostszym rozwiazaniem byloby chyba zawarcie tej konfiguracji w zmodyfikowanym skrypcie Gradle Wrappera.

Ok, to jest jakieś rozwiązanie. Ciekawe jak to by wtedy z demonem
współgrało, ale jest jakiś pomysł.

Dawid

[Marcin Erdmann]

Nie widze zadnych powodow dla ktorych taka konfiguracja moglaby byc problematyczna jak chodzi o demona.

--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „Poznań Java User Group”.

Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości, wyślij e-maila na jug-poznan+...@googlegroups.com.

Aby zamieszczać posty w tej grupie, wyślij e-mail na adres jug-p...@googlegroups.com.
Odwiedź tę grupę na http://groups.google.com/group/jug-poznan

[Dawid Weiss]

Zmienne środowiskowe odpalonego skryptu są przekazywane/ respektowane
przez demona (pytam, nie wiem, nie sprawdzałem)? To powinno być dość
proste do weryfikacji w praniu w każdym razie, dzięki za wskazówkę.

Dawid

> --
> Otrzymujesz tę wiadomość, bo subskrybujesz grupę „Poznań Java User Group” w
> Grupach dyskusyjnych Google.

> Aby anulować subskrypcję tej grupy i przestać otrzymywać od niej wiadomości,
> wyślij e-maila na jug-poznan+...@googlegroups.com.

> Aby opublikować wpis w tej grupie, wyślij e-maila na
> jug-p...@googlegroups.com.
> Otwórz tę grupę na http://groups.google.com/group/jug-poznan.

> Więcej opcji znajdziesz na https://groups.google.com/d/optout.

[Marcin Erdmann]

Jak chodzi o przekazywanie wlasnosci systemowych to nie sa one przekazywane (trzeba je przekazac jako argumenty dla JVMa poprze wlasnosc org.gradle.jvmargs, https://gradle.org/docs/current/userguide/build_environment.html) a zmienne srodowiskowe zwiazane z konfiguracja Gradle sa ignorowane przez demona bo jest on konfigurowany przez proces ktory go odpala. Jestem przekonany, ze demon bedzie dzialal przy uzyciu inego niz domyslny katalogu domowego Gradle.

[Dawid Weiss]

Cześć!

Sprawdziłem sobie z ciekawości jak się ma speedup (bez demona)
względem tego, co używaliśmy dotychczas (gradle 1.9). Wyniki są
intrygujące -- to jest build w którym wszystko jest up-to-date (czyli
nic się de facto nie buduje):

1.9

Total time: 4.706 secs
Total time: 4.684 secs
Total time: 4.737 secs

2.3

Total time: 4.97 secs
Total time: 4.933 secs
Total time: 5.024 secs

2.4-rc-2

Total time: 5.194 secs
Total time: 5.151 secs
Total time: 5.148 secs

Komputer jest już nieco leciwy -- i7 860 @ 2.8GHz, 8G ramu i szybki
intelowski SSD.

Nic nie podważam co do usprawnień w 2.4, ale u mnie ich nie widać :)

Dawid

[Marcin Erdmann]

Ciekawe. A to jest jakis publiczny build, zebym mogl sobie go obejrzec w profilerze w wolnej chwili?

Ogolnie, to powinienes sprobowac z daemonem, bo wiekszosc usprawnien (m.in. cacheowanie class loaderow, https://gradle.org/docs/current/release-notes#improved-performance-of-gradle-daemon-via-class-reuse) widac tylko jak sie go uzywa.

[Dawid Weiss]

> Ciekawe. A to jest jakis publiczny build, zebym mogl sobie go obejrzec w
> profilerze w wolnej chwili?

No niestety nie :(

> Ogolnie, to powinienes sprobowac z daemonem

Ja używam demona, Marcin (cóż za zdanie...), tylko tak jak Ci mówiłem
-- znam oczekiwania innych programistów, którzy z jednej strony
chcieliby szybki start (pierwsze uruchomienie), a z drugiej boją się
trochę o zasoby systemowe i samej koncepcji demona...

To nie jest problem, gradle rządzi i tak w porównaniu z innymi build-systemami.

Dawid

[Marcin Erdmann]

Troche szkoda, ze ci "inni programisci" maja takie podejscie do tematu, choc nie jest moze tak zupelnie oderwane od rzeczywistosci. Ogolnie z tego co sie orientuje to nasza strategia na poprawienie wydajnosci bedzie w najblizszym czasie polegac na tym, ze bedziemy coraz wiecej rzeczy usprawniac w demonie, bo to nasza jedyna opcja zeby cacheowac rzeczy w pamieci. Kto sie boi demona ten traci. :)

Dawid