Taki tam rant po Gradle i Dockerze ;-)

Jest coś takiego jak standardy, jest też coś takiego jak od lat stosowane praktyki.

Gdy jeszcze nie było Internetu, a był ARPANET to komputery "widziały" się tylko po adresach IP.
To ludziom przeszkadzało, bo czasem fajnie było wiedzieć, że łączymy się do maszyny o nazwie ALICE zamiast do jakiegoś zbitka 4 liczb oddzielonych kropkami.
Więc ludzie zaczęli tworzyć pliki HOSTS.TXT, w których były zapisane mapowania adresów tekstowych na adresy IP.
W końcu wyewoluowało to z jednej strony w DNS, z drugiej w /etc/hosts, czyli plik w którym administrator lokalnej maszyny może zapisać swoje mapowania.
Przestrzega tego Linux i inne *niksy, przestrzega Windows (z ciut inną lokalizacją), przestrzega macOS.
Ale nie działa to z Dockerem ;-)
Przynajmniej w domyślnej konfiguracji.
Docker ma w głębokim poważaniu to co jest skonfigurowane w /etc/hosts jego hosta, z tego co widziałem olewa też to co ma w swoim.
Dopiero dodanie mu przełącznika -net=host powoduje, że zaczyna być świadom tego pliku.

Kiedyś wymyślono też coś takiego jak Exit code z aplikacji.
Jeśli aplikacja zwraca coś innego niż 0 to jest to error code i informacja dla procesu, który ją wywołuje, że wróciła z błędem.
POSIX to nawet "ustandaryzował" i wymaga by każdy OS który jest zgodny z POSIX stosował się do tego schematu.
Do tego w *niksach wprowadzono, a później przeszło to do innych OSów podział konsoli na konsolę i konsolę błędów. Idea była taka, że na konsolę błędów powinny iść wszystkie informacje, które są lub mogą być istotne w troubleshootingu.
I w pewnym momencie przyszli ludzie piszący Gradle'a. W swym szaleństwie uznali, że kto by tam bazował na jakimś kodzie wyjścia z aplikacji w celu uznania, że aplikacja skończyła się z błędem.
Uznali, że oni wiedzą lepiej i dlatego jeśli przez ich Exec czy jak to się zowie task odpali jakiś zewnętrzny proces i ten proces zapisze coś do konsol błędów to nawet gdy zwróci 0 mówiące, że skończył się z sukcesem to oni uznają, że wiedzą lepiej i zgłoszą, że był fail.
Teraz dodajmy do tego to, że jeśli używa się _JAVA_OPTIONS do nadpisania jakichś ustawień JRE to JRE wypisze na konsolę błędów, że użyje wartości z _JAVA_OPTIONS to mamy to, że taki proces w Java'ie nie będzie się nigdy w Gradle kończył sukcesem ;-)

Jak już o Gradle mowa.
Zwyczajowo robi się tak, że jak Twój kod jest odpalany w jakimś katalogu, to jest to katalog roboczy i wszystkie operacje które się robi powinno się robić względem tego katalogu.
Gradle tak robił, ale już nie robi ;-) Gradle 5.0 wie lepiej i robi tak. Jeśli w tasku wykonuje się kod w Java'ie i ten kod odpali proces, to ten proces odpali się w katalogu roboczym (startowym), ale pliki widziane przez ten kod będą w katalogu z którego startuje któraś tam "warstwa" wrappera Gradle'a ;-)


Podobne posty^beta
Rant po toolach w stylu Mavane, Gradle, Bowera i całej tej hałastry
A ja wybrałem Xbox One ;-)
Gdzie popełniliśmy błąd?
Serwisy mniejszej miłości ;-)
Jak zmusić Gradle'a do używania ramdysku (na OS X)