Jakieś problemy? Zapraszamy na leżankę.
Buildery są znami
Historia make sięga lat 80-tych. W C++ był makebuilder, o plikach makefile chyba słyszał każdy z nas. W Javie był swego czasu antbuilder. Teraz mamy Gradle.
Uczący się Javy i słyszący o dobrodziejstwach Gradle mają pewne oczekiwania, przede wszystkim to, że narzędzie będzie miało prosty proces konfiguracji i konfiguracji, i że wszystko będzie wyglądało dość znajomo. Zamiast tego Gradle jest dla wielu, hm - tajemniczy. Okazuje się, że niestety ale traktowanie Gradle’a jako ćwiczenia z szybkiej konfiguracji po prostu nie działa. Nie możesz podejść do tego z niecierpliwą postawą. Podstawowy problem, który jest z Gradle można ująć tak: „żeby umieć zrobić cokolwiek musisz wiedzieć wszystko”.
Podstawy
Tak, hipotetycznie możliwe jest utworzenie prostego pliku build.gradle dla wersji podstawowej projektu. Ale zwykle będziesz zaraz musiał zrobić więcej. Okazuje się, że „robienie więcej” oznacza „wiedzieć wszystko”. Gdy miniesz proste rzeczy, spadniesz z klifu.
Praktycznie każdy system kompilacji ma dwa podstawowe składniki:
- Zadania: zawierają czynności dla Twojej kompilacji. Kompilacja zwykle składa się z wielu zadań i zwykle wywołujesz żądane zadanie z wiersza poleceń, tak jak w przypadku kompilacji Gradle. Inne systemy kompilacji mają różne nazwy zadań.
- Zależności: zależność mówi to nie może się zdarzyć, zanim to się stanie. Zwykle oznacza to Nie mogę skompilować / uruchomić tego komponentu, zanim ten komponent nie będzie dostępny / zaktualizowany, ale zależność może odnosić się do dowolnej kolejności, która mówi Zrób to najpierw, a potem zrób tamto.
Zależności można traktować jako „wewnętrzne” (polegające na innych komponentach w kompilacji) lub „zewnętrzne” (aktualizowanie komponentów z repozytoriów zewnętrznych, lokalnych lub zdalnych).
Narzędzie do budowania czyta skrypt, który zwykle znajduje się w pliku o standardowej nazwie, takiej jak build.gradle. Na podstawie instrukcji zawartych w skrypcie narzędzie kompilacji wykonuje operacje niezbędne do zaktualizowania projektu.
Nie konfigurujesz, tylko programujesz
Chociaż Gradle próbuje wyglądać, jakby tylko deklarował konfiguracje, każda z tych konfiguracji jest w rzeczywistości wywołaniem funkcji. Zasadniczo wszystko, z wyjątkiem niektórych dyrektyw językowych, albo tworzy obiekty, albo wywołuje funkcje. Ta zapomniana prawda jest bardzo pomocna, ponieważ teraz możesz spojrzeć na deklaracje konfiguracji i zauważyć, że faktycznie wywołują funkcje - a to ułatwi Ci zrozumienie tego co się dzieje.
Groovy to nie Java
Będziesz musiał opanować znaczną część języka Groovy, aby tworzyć prawidłowe pliki kompilacji Gradle. Prawie niemożliwe jest zrozumienie, co się dzieje, zanim nie zanurzysz się wystarczająco głęboko w Groovy. Składnia Groovy przypomina Javę, ale jest to inny język i musisz nauczyć się nowego zestawu reguł. Fakt, że Groovy ma dostęp do istniejących bibliotek Java, jest przede wszystkim korzyścią dla programistów Gradle. Zrozumienie Kotlina także pozwala zrozumieć Groovy'ego.
Gradle używa języka specyficznego dla domeny
Język specyficzny dla domeny (DSL) jest wyspecjalizowany w określonej domenie aplikacji. Celem tak zwanego wewnętrznego DSL (takiego, który jest zbudowany w ramach istniejącego języka) jest zawężenie uwagi do danego problemu (np. właśnie konfiguracji kompilacji oprogramowania), tak aby użytkownik musiał rozumieć DSL tylko o tyle aby wykonać zleconą mu pracę.
Na przykład, aby powiedzieć Gradle, gdzie znaleźć pliki źródłowe Java, możesz powiedzieć:
sourceSets {
main {
java {
srcDirs 'java11'
}
}
}
Ma to na celu stworzenie deklaratywnego sposobu opisywania twoich kompilacji i opiera się na składni lambd Groovy. Tak więc sourceSets, main i java są wywołaniami funkcji, ale wynikowa składnia sprawia, że wygląda to jak… coś innego.
Jest wiele sposobów na zrobienie tego samego
Groovy pozwala ci wyrażać rzeczy na wiele różnych sposobów, a dokumentacja Gradle wydaje się rozkoszować tą różnorodnością. Kiedy tylko próbujesz przez to przejść, natychmiastowe dodanie odmian tylko to utrudnia. Co gorsza, ludzie mają tendencję do przypadkowego stosowania różnych podejść, więc musisz rozpoznać i rozwikłać konkurujące składnie.
Na przykład poprzednie zestawy źródłowe można również skonfigurować za pomocą składni wywołania funkcji, dodając nawiasy:
sourceSets {
main {
java {
srcDirs ('java11')
}
}
Możesz też pominąć składnię DSL i napisać ją bardziej zwięźle:
sourceSets.main.java.srcDirs = ['java11']
Co jest równoważne z:
sourceSets.main.java.srcDirs ('java11')
Możesz wybierać spośród różnych podejść i ludzie to robią, więc czytając przykłady kodu, musisz zrozumieć wszystkie odmiany. To potęguje złożoność uczenia się Gradle.