Dlaczego Gradle Wrapper miałby być zaangażowany w VCS?

148

Z dokumentacji Gradle: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html

Skrypty wygenerowane przez to zadanie mają zostać wprowadzone do systemu kontroli wersji. To zadanie generuje również mały plik JAR bootstrap gradle-wrapper.jar i plik właściwości, które również powinny zostać zapisane w systemie VCS. Skrypty są delegowane do tego pliku JAR.

Od: Czego NIE powinno być pod kontrolą źródła?

Myślę, że Generated filesnie powinno być w VCS.

Kiedy są gradlewi gradle/gradle-wrapper.jarpotrzebne?

Dlaczego nie zapisać gradle versionw build.gradlepliku?

version-control gradle

— farmer1992
źródło

1

Ciekawą dyskusją poboczną, biorąc pod uwagę poniższe odpowiedzi, jest przydatność tych plików, jeśli używasz jakiejś formy narzędzia do ciągłej integracji. Które z nich sprawdzą, czy jest opakowanie klasy i użyją go, jeśli tam jest?

— lilbyrdie

124

Ponieważ celem programu gradle wrapper jest możliwość, bez konieczności instalowania gradle i nawet nie wiedząc, jak to działa, skąd go pobrać, z której wersji, sklonować projekt z VCS, wykonać skrypt gradlew to zawiera i skompilować projekt bez dodatkowego kroku.

Gdyby wszystko, co miałeś, to numer wersji gradle w pliku build.gradle, potrzebowałbyś README wyjaśniającego wszystkim, że wersja Gradle X musi zostać pobrana z adresu URL Y i zainstalowana, i musiałbyś to robić za każdym razem, gdy wersja jest zwiększana.

— JB Nizet
źródło

94

To głupie. gradle-wrapper.jar nie powinien być potrzebny w VCS. W razie potrzeby Gradle powinien móc pobrać dowolną wersję po zainstalowaniu pierwszej. Łańcuch narzędzi nie ma nic wspólnego z VCS… Rozumiem, że twoja odpowiedź jest prawidłowa i jest to projekt Gradle. Ale ten projekt jest absurdalny.

— Marc Plano-Lesay

26

Chodzi o to, aby móc pobrać gradle bez wcześniejszego instalowania go . Jaki jest problem z posiadaniem pliku o rozmiarze 50 KB w VCS?

— JB Nizet,

59

Problem w tym, że to nie jest część projektu. To narzędzie, którego używasz do tworzenia projektu. Nie będziesz przechowywać JDK w VCS, prawda? Ani GCC dla aplikacji C? Dlaczego więc miałbyś przechowywać część Gradle? Jeśli programista nie jest w stanie samodzielnie odczytać i zainstalować Gradle, to kolejny problem.

— Marc Plano-Lesay

26

Problem polega również na tym, że nie pamiętasz, 2 lata po wydaniu, która wersja Gradle została użyta do zbudowania wersji v1.0 twojego oprogramowania, że musisz naprawić dla klienta, który nadal używa tej wersji 1.0 wersja i nie można zaktualizować. Opakowanie gradle rozwiązuje to, że: klonujesz tag 1.0 z VCS, tworzysz go za pomocą gradlew i używa wersji gradle, która była używana 2 lata temu do zbudowania wersji 1.0.

— JB Nizet,

33

Zgadzam się, że wersja Gradle, która ma być używana, musi być wskazana gdzieś w projekcie. Ale Gradle to narzędzie zewnętrzne , nic nie porównywalne z plikiem README lub czymkolwiek, co wymieniłeś. Gradle powinien być w stanie samodzielnie pobrać odpowiednią wersję, bez konieczności przechowywania jar w VCS.

— Marc Plano-Lesay

80

Ponieważ celem owijania gradle jest to, aby móc bez konieczności instalowania gradle

Ten sam argument dotyczy JDK, czy chcesz to również zatwierdzić? Czy oddajesz również wszystkie swoje biblioteki zależne?

Zależności należy aktualizować w sposób ciągły w miarę wydawania nowych wersji. Aby uzyskać zabezpieczenia i inne poprawki błędów. A ponieważ jeśli zajdziesz daleko w tyle, może to być bardzo czasochłonne zadanie, aby ponownie być na bieżąco.

Jeśli otoka gradle jest zwiększana dla każdej nowej wersji i jest zatwierdzona, repozytorium będzie bardzo duże. Problem jest oczywisty podczas pracy z rozproszonym systemem VCS, w którym klon pobierze wszystkie wersje wszystkiego.

i nawet nie wiedząc, jak to działa

Utwórz skrypt kompilacji, który pobiera opakowanie i używa go do kompilacji. Nie każdy musi wiedzieć, jak działa skrypt, musi zgodzić się, że projekt buduje się poprzez jego wykonanie.

, skąd go pobrać, która wersja

task wrapper(type: Wrapper) {
 gradleVersion = 'X.X' 
}

I wtedy

gradle wrapper

Aby pobrać odpowiednią wersję.

, aby sklonować projekt z VCS, wykonać skrypt gradlew, który zawiera, i zbudować projekt bez żadnych dodatkowych kroków.

Rozwiązany przez powyższe kroki. Pobieranie opakowania gradle nie różni się od pobierania jakichkolwiek innych zależności. Skrypt może być sprytny, aby sprawdzić, czy nie ma żadnego aktualnego opakowania gradle i pobrać go tylko wtedy, gdy jest nowa wersja.

Jeśli programista nigdy wcześniej nie korzystał z Gradle i być może nie wiedząc, że projekt jest budowany za pomocą Gradle. Wtedy bardziej oczywiste jest uruchomienie pliku „build.sh” w porównaniu z uruchomieniem „gradlew build”.

Gdyby wszystko, co miałeś, to numer wersji gradle w pliku build.gradle, potrzebowałbyś README wyjaśniającego wszystkim, że wersja gradle X musi zostać pobrana z adresu URL Y i zainstalowana,

Nie, nie potrzebujesz pliku README. Możesz go mieć, ale my jesteśmy programistami i powinniśmy automatyzować jak najwięcej. Tworzenie skryptu jest lepsze.

i musiałbyś to robić za każdym razem, gdy wersja jest zwiększana.

Jeśli programiści zgodzą się, że prawidłowy proces to:

Sklonuj repozytorium
Uruchom skrypt kompilacji

Wtedy uaktualnienie do najnowszej owijarki gradle nie stanowi problemu. Jeśli wersja została zwiększona od ostatniego uruchomienia, skrypt może pobrać nową wersję.

— Tomas Bjerre
źródło

2

„Zależności powinny być stale aktualizowane”. Tak, patrząc w przyszłość. Nie, patrząc wstecz. Aby odtworzyć starą kompilację, musisz mieć określone wersje zależności. Gradle sprawia, że niektóre typy projektów są szybsze i łatwiejsze w obsłudze. Byłby to bałagan w organizacji, która potrzebowała reprodukcji i audytu.

— lilbyrdie

3

Nie bardzo wiem, co masz na myśli. Ale jeśli masz build.gradlekontrolę wersji i masz w niej: task wrapper(type: Wrapper) { gradleVersion = 'X.X' } Następnie gradle wrapperpobierzesz opakowanie, które było używane, i będziesz mógł odtworzyć starą wersję .

— Tomas Bjerre

1

Miał na myśli twój wiersz dotyczący zależności, a nie wersji gradle. Jasne, chcesz, aby Twoje biblioteki miały wszystkie najnowsze poprawki zabezpieczeń i błędów, ale NIE, gdy próbujesz odtworzyć starą kompilację, być może w celach audytowych lub prawnych. Chcesz, aby Twoje biblioteki i proces kompilacji były w stanie wygenerować binarne identyczne dane wyjściowe, jeśli to w ogóle możliwe. Podobnie jak w przypadku zależności od biblioteki, nie ma gwarancji, że konkretna wersja będzie dostępna w momencie tworzenia ... czy to za 2 tygodnie, czy za dwie dekady. Więc tak, w przypadku niektórych projektów jest to to samo, co biblioteki i zestawy SDK.

— lilbyrdie

3

Myślę, że opakowanie jest tam przede wszystkim z powodów historycznych. Na początku wszyscy używają Mavena i nikt nie ma zainstalowanego Gradle. Trudno byłoby przekonać współpracownika do zainstalowania nieznanych, natrętnych zależności, więc opakowanie pomaga im załadować. Obecnie każdy ma już Gradle, a opakowanie staje się zbędne.

— Franklin Yu

1

Czy sugerujesz wykonanie gradle wrapperpo sklonowaniu na każdej kompilacji? Zasadniczo sprawia to, że opakowanie jest bezużyteczne, ponieważ chodzi o to, że nie trzeba lokalnie instalować Gradle, aby zbudować projekt !

— Xerus

41

Chciałbym polecić proste podejście.

W pliku README projektu udokumentuj, że wymagany jest etap instalacji, a mianowicie:

gradle wrapper --gradle-version 3.3

Działa to z Gradle 2.4 lub nowszym. Tworzy to opakowanie bez konieczności dodawania dedykowanego zadania do pliku „build.gradle”.

Dzięki tej opcji zignoruj (nie wpisuj) te pliki / foldery w celu kontroli wersji:

./gradle
gradlew
gradlew.bat

Główną korzyścią jest to, że nie musisz wpisywać pobranego pliku do kontroli źródła. Instalacja kosztuje jeden dodatkowy krok. Myślę, że warto.

— David J.
źródło

15

dlaczego miałbyś wtedy potrzebować opakowania? Cała idea wrappera polega na tym, że możesz budować projekt bez konieczności posiadania gradle w systemie.

— edio

4

Niezłe rozwiązanie. Brak plików binarnych w git i nadal można używać gradlew. @edio będzie potrzebny do pobrania i używania określonej wersji gradle.

— Kirill

3

Co to jest „projekt”?

Może istnieje techniczna definicja tego idiomu, która wyklucza skrypty budowania. Ale jeśli zaakceptujemy tę definicję, to musimy powiedzieć, że twój „projekt” to nie wszystko, co musisz wersjonować!

Ale jeśli powiemy „Twój projekt”, to wszystko , co zrobiłeś . Wtedy możemy powiedzieć, że musisz to włączyć i tylko to do VCS.

Jest to bardzo teoretyczne i może nie praktyczne w przypadku naszych prac rozwojowych. Więc zmieniamy to na „ Twój projekt to każdy plik (lub folder), który musisz edytować bezpośrednio ”.

^{„bezpośrednio” oznacza „nie pośrednio”, a „pośrednio” oznacza edycję innego pliku, a efekt zostanie odzwierciedlony w tym pliku .}

Więc dochodzimy do tego samego, co powiedział OP (i jest tutaj powiedziane ):

Myślę, że wygenerowane pliki nie powinny znajdować się w VCS.

Tak. Bo ty nie stworzył ich. Nie są więc częścią „Twojego projektu” zgodnie z drugą definicją.

Jaki jest wynik w przypadku tych plików:

build.gradle : Tak. Musimy to edytować. Nasze prace powinny być wersjonowane.

Uwaga: nie ma różnicy, gdzie go edytujesz. Czy to w środowisku edytora tekstu, czy w środowisku GUI struktury projektu . Zresztą pan robi to bezpośrednio !
gradle-wrapper.properties : Tak. Musimy przynajmniej określić wersję Gradle w tym pliku.
gradle-wrapper.jar i gradlew [.bat] : Do tej pory nie tworzyłem ani nie edytowałem ich w żadnej z moich prac rozwojowych! Tak więc odpowiedź brzmi „nie”. Jeśli to zrobiłeś, odpowiedź brzmi „Tak”, jeśli chodzi o Ciebie w tej pracy (i ten sam plik, który edytowałeś).

Ważna uwaga o najnowszych przypadku jest użytkownik, który klonuje swoje repo, musi wykonać to polecenie na repo<root-directory> do automatycznego generowania otoki pliki:

> gradle wrapper --gradle-version=$v --distribution-type=$distType

$vi $distTypesą określane na podstawie gradle-wrapper.properties :

distributionUrl=https\://services.gradle.org/distributions/gradle-{$v}-{$distType}.zip

Więcej informacji można znaleźć pod adresem https://gradle.org/install/ .

gradleplik wykonywalny jest bin/gradle[.bat]w dystrybucji lokalnej. Nie jest wymagane, aby dystrybucja lokalna była taka sama, jak określona w repozytorium. Po utworzeniu plików opakowującychgradlew[.bat] można automatycznie pobrać określoną dystrybucję Gradle (jeśli nie istnieje lokalnie). Następnie prawdopodobnie musi zregenerować pliki opakowujące przy użyciu nowego gradlepliku wykonywalnego (w pobranej dystrybucji) zgodnie z powyższymi instrukcjami.

Uwaga: w powyższych instrukcjach założono, że użytkownik ma lokalnie przynajmniej jedną dystrybucję Gradle (np ~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10.). Obejmuje prawie wszystkie rzeczywiste przypadki. Ale co się stanie, jeśli użytkownik nie ma już żadnej dystrybucji?

Może ją pobrać ręcznie, korzystając z adresu URL w .propertiespliku. Ale jeśli nie zlokalizuje go w ścieżce, której oczekiwał opakowanie , opakowanie pobierze go ponownie! Oczekiwana ścieżka jest całkowicie przewidywalna, ale jest poza tematem (zobacz tutaj, aby zobaczyć najbardziej złożoną część).

Jest też kilka łatwiejszych (ale brudnych) sposobów. Na przykład może skopiować pliki opakowujące (z wyjątkiem .propertiesplików) z dowolnego innego lokalnego / zdalnego repozytorium do swojego repozytorium, a następnie uruchomić je gradleww swoim repozytorium. Automatycznie pobierze odpowiednią dystrybucję.

— Mir-Ismaili
źródło

1

Stare pytanie, nowa odpowiedź. Jeśli nie aktualizujesz gradle często (większość z nas tego nie robi), lepiej oddać to do VCS. Głównym powodem jest dla mnie zwiększenie szybkości kompilacji na serwerze CI. Obecnie większość projektów jest budowana i instalowana przez serwery CI, za każdym razem inna instancja serwera.

Jeśli tego nie zrobisz, serwer CI będzie pobierał jar dla każdej kompilacji i znacznie wydłuża czas kompilacji. Istnieją inne sposoby rozwiązania tego problemu, ale uważam, że ten jest najłatwiejszy w utrzymaniu.

— smgn
źródło

0

Zgodnie z dokumentacją Gradle , oczekuje się dodania gradle-wrapper.jardo VCS, ponieważ udostępnienie Gradle Wrapper programistom jest częścią podejścia Gradle:

Aby udostępnić pliki Wrappera innym programistom i środowiskom wykonawczym, musisz sprawdzić je w kontroli wersji. Wszystkie pliki Wrappera, w tym plik JAR, mają bardzo mały rozmiar. Oczekuje się dodania pliku JAR do kontroli wersji. Niektóre organizacje nie zezwalają projektom na przesyłanie plików binarnych do kontroli wersji. W tej chwili nie ma alternatywnych opcji podejścia.

— Arthur Khazbs
źródło