Чому слід обкладати Gradle Wrapper на VCS?

З документації Gradle: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html

Сценарії, згенеровані цим завданням, призначені для передачі у вашу систему управління версіями. Це завдання також генерує невеликий завантажувальний файл JAR-файлу gradle-wrapper.jar і файл властивостей, який також повинен бути присвячений вашому VCS. Сценарії делегують цьому JAR.

Від: Що НЕ повинно бути під контролем джерела?

Я думаю, Generated filesне повинно бути в ДКС.

Коли gradlewі gradle/gradle-wrapper.jarпотрібні?

Чому б не зберегти файл gradle versionу build.gradleфайлі?

Тому що вся суть оболонки gradle полягає в тому, щоб мати змогу, не встановлюючи ніколи Gradle, і навіть не знаючи, як це працює, звідки його завантажити, в якій версії, клонувати проект з VCS, виконувати скрипт gradlew містить і створити проект без будь-якого додаткового кроку.

Якщо б у вас був номер версії gradle у файлі build.gradle, вам знадобиться README, який пояснює всім, що версія gradle X повинна бути завантажена з URL-адреси Y та встановлена, і вам доведеться робити це кожного разу, коли версія збільшується.

Тому що вся суть обгортки граділь має бути здатною, не встановлюючи ніколи Gradle

Цей же аргумент стосується і JDK, чи хочете ви також це зробити? Ви також надаєте всі свої бібліотеки залежних?

Після виходу нових версій залежність слід постійно оновлювати. Щоб отримати безпеку та інші виправлення помилок. А тому, що якщо ви потрапите далеко позаду, це може бути дуже трудомістким завданням знову бути в курсі.

Якщо обгортка gradle збільшуватиметься для кожного нового випуску, і він виконаний, репо зросте дуже великим. Проблема очевидна при роботі з розподіленим VCS, де клон завантажує всі версії всього.

, і навіть не знаючи, як це працює

Створіть сценарій збірки, який завантажує обгортку і використовує її для створення. Кожному не потрібно знати, як працює сценарій, їм потрібно погодитись, що проект будується шляхом його виконання.

, звідки його завантажити, в якій версії

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

І потім

gradle wrapper

Щоб завантажити правильну версію.

, клонувати проект з VCS, виконувати скрипт gradlew, який він містить, і будувати проект без будь-якого додаткового кроку.

Вирішується описаними вище кроками. Завантаження обгортки gradle не відрізняється від завантаження будь-яких інших залежностей. Сценарій міг би бути розумним, щоб перевірити наявність поточної обгортки gradle та завантажити його лише за наявності нової версії.

Якщо розробник ніколи раніше не використовував Gradle і, можливо, не знаючи, що проект будується з Gradle. Тоді більш очевидним є запуск "build.sh" порівняно із запуском "gradlew build".

Якщо б у вас був номер версії gradle у файлі build.gradle, вам знадобиться README, що пояснює всім, що версія gradle X повинна бути завантажена з встановленої URL-адреси Y,

Ні, вам не знадобиться README. Ви можете мати його, але ми розробники, і ми повинні максимально автоматизувати. Створення сценарію краще.

і вам доведеться робити це кожного разу, коли версія збільшується.

Якщо розробники погоджуються, що правильний процес:

1. Клонований репо
2. Запустити сценарій збірки

Тоді оновлення до останньої оболонки gradle - це не проблема. Якщо версія нарощується з моменту останнього запуску, сценарій може завантажити нову версію.

Я хотів би порекомендувати простий підхід.

У вашому проекті README документуйте, що необхідний крок встановлення, а саме:

gradle wrapper --gradle-version 3.3

Це працює з Gradle 2.4 або вище. Це створює обгортку, не вимагаючи додавання спеціального завдання до "build.gradle".

За допомогою цієї опції ігноруйте (не забувайте) ці файли / папки для контролю версій:

• ./gradle
• gradlew
• gradlew.bat

Основна перевага полягає в тому, що вам не потрібно реєструвати завантажений файл для управління джерелом. Це коштує один додатковий крок при встановленні. Я думаю, що воно того варте.

Що таке "проект"?

Можливо, є технічне визначення цієї ідіоми, яке виключає сценарії побудови. Але якщо ми приймаємо це визначення, тоді ми повинні сказати, що ваш "проект" - це не все те, що вам потрібно переосмислити!

Але якщо ми скажемо "ваш проект" - це все, що ви зробили . Тоді ми можемо сказати, що ви повинні включити його і тільки це в VCS.

Це дуже теоретично і, можливо, не практично у випадку наших розробок. Тому ми змінюємо його на " ваш проект - це кожен файл (або папка), який вам потрібно редагувати безпосередньо ".

^{"безпосередньо" означає "не побічно", а "опосередковано" означає редагування іншого файлу, і тоді ефект буде відображений у цьому файлі .}

Таким чином , ми досягаємо того ж , що OP сказав (і , як кажуть тут ):

Я думаю, що згенеровані файли не повинні знаходитись у VCS.

Так. Тому що ви їх не створили. Тож вони не є частиною "вашого проекту" згідно з другим визначенням.

Який результат у цих файлах:

• build.gradle : Так. Нам потрібно це відредагувати. Наші роботи повинні бути виокремленими.

  Примітка. Немає різниці, де ви їх редагуєте. Чи в середовищі редактора тексту чи в інтерфейсі GUI структури структури . Все одно ви це робите безпосередньо !

• gradle-wrapper.properties : Так. Нам потрібно принаймні визначити версію Gradle у цьому файлі.

• gradle-wrapper.jar та gradlew [.bat] : Я до цього моменту не створював і не редагував жодної з моїх робіт з розробки! Тож відповідь - «Ні». Якщо ви це зробили, відповідь "Так" про вас на цій роботі (і приблизно того самого файлу, який ви редагували).

Важливе зауваження про останньому випадку це користувач , який клонує ваше сховище, необхідно виконати цю команду на репо<root-directory> для автоматичного створення обгортки файлів:

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

$vі $distTypeвизначаються з gradle-wrapper.properties :

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

Див. Https://gradle.org/install/ для отримання додаткової інформації.

gradleвиконується bin/gradle[.bat]в локальному розповсюдженні. Не потрібно, щоб локальний розподіл був таким самим, як визначений у репо. Після створених файлів обгорткиgradlew[.bat] можна автоматично завантажити визначений розподіл Gradle (якщо він не існує локально). Тоді він / вона, ймовірно, повинен регенерувати обгорткові файли, використовуючи новий gradleвиконуваний файл (у завантаженому дистрибутиві), використовуючи вищезазначені інструкції.

Примітка. У наведених вище інструкціях, припускається, що користувач має принаймні один розподіл Gradle локально (наприклад ~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10). Він охоплює майже всі реальні випадки. Але що станеться, якщо користувач вже не має жодного розповсюдження?

Він / вона може завантажити його вручну за допомогою URL-адреси у .propertiesфайлі. Але якщо він / вона не знайде його на шляху, який очікувала обгортка , обгортка завантажить його знову! Очікуваний шлях є цілком передбачуваним, але є поза темою (дивіться тут найбільш складну частину).

Є також більш прості (але брудні) способи. Наприклад, він / вона може скопіювати обгорткові файли (крім .propertiesфайлу) з будь-якого іншого локального / віддаленого сховища до свого сховища, а потім запустити gradlewйого в своє сховище. Він автоматично завантажить відповідний дистрибутив.

Старе запитання, свіжа відповідь. Якщо ви не оновлюєте gradle часто (більшість з нас це не робить), краще скористатись VCS. І головна причина для мене - збільшити швидкість збірки на сервері CI. Сьогодні більшість проектів будуються та встановлюються серверами CI, кожен раз різними екземплярами сервера.

Якщо ви цього не зробите, сервер CI завантажить банку для кожної збірки, і це значно збільшує час збірки. Є й інші способи впоратися з цією проблемою, але я вважаю цей спосіб найпростішим у обслуговуванні.

Згідно з документами Gradle , очікується , що додавання gradle-wrapper.jarдо VCS, оскільки надання Gradle Wrapper доступним для розробників є частиною підходу Gradle:

Щоб зробити файли Wrapper доступними для інших розробників та середовищ виконання, вам потрібно перевірити їх у контролі версій. Усі файли Wrapper, включаючи файл JAR, мають дуже малі розміри. Очікується додавання файлу JAR до контролю версій. Деякі організації не дозволяють проектам надсилати бінарні файли до контролю версій. На даний момент альтернативних варіантів підходу немає.