Из документации Gradle: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html
Сценарии, сгенерированные этой задачей, предназначены для фиксации в вашей системе контроля версий. Эта задача также генерирует небольшой файл JAR загрузочного файла gradle-wrapper.jar и файл свойств, которые также должны быть переданы вашей VCS. Сценарии делегатов для этого JAR.
От: Что НЕ должно находиться под контролем источников?
Я думаю, что Generated filesне должно быть в VCS.
Когда gradlewи gradle/gradle-wrapper.jarнужны?
Почему бы не сохранить gradle versionв build.gradleфайле?
version-control
gradle
farmer1992
источник
источник
Ответы:
Потому что весь смысл оболочки Gradle заключается в том, чтобы иметь возможность, даже не устанавливая gradle, и даже не зная, как он работает, откуда его загружать, с какой версии, чтобы клонировать проект из VCS, выполнить его сценарий gradlew содержит, и построить проект без каких-либо дополнительных шагов.
Если все, что у вас было, это номер версии Gradle в файле build.gradle, вам понадобится README, объясняющий всем, что версия X Gradle должна быть загружена с URL Y и установлена, и вам придется делать это при каждом увеличении версии.
источник
То же самое относится и к JDK, вы тоже хотите это зафиксировать? Вы также фиксируете все свои зависимые библиотеки?
Зависимости должны постоянно обновляться по мере выпуска новых версий. Чтобы получить безопасность и другие исправления ошибок. И потому, что если вы далеко позади, это может быть очень трудоемкой задачей, чтобы обновиться.
Если оболочка Gradle увеличивается для каждого нового выпуска и фиксируется, репо будет очень большим. Проблема очевидна при работе с распределенной VCS, где клон будет загружать все версии всего.
Создайте скрипт сборки, который загружает оболочку и использует ее для сборки. Всем не нужно знать, как работает скрипт, они должны согласиться с тем, что проект создается путем его выполнения.
А потом
Чтобы скачать правильную версию.
Решено по шагам выше. Загрузка оболочки Gradle не отличается от загрузки любых других зависимостей. Сценарий может быть разумным, чтобы проверить наличие любой текущей оболочки Gradle и загружать ее только при наличии новой версии.
Если разработчик никогда не использовал Gradle и, возможно, не знает, что проект собирается с Gradle. Тогда более очевидно запускать «build.sh» по сравнению с «gradlew build».
Нет, вам не нужно README. Вы могли бы иметь один, но мы разработчики, и мы должны максимально автоматизировать. Создание сценария лучше.
Если разработчики согласны с тем, что правильный процесс заключается в следующем:
Тогда обновление до последней версии Gradle не является проблемой. Если версия увеличивается с момента последнего запуска, скрипт может загрузить новую версию.
источник
build.gradleконтроль версий, и у вас есть:task wrapper(type: Wrapper) { gradleVersion = 'X.X' }Затемgradle wrapperзагрузите используемую оболочку, и вы сможете воспроизвести старую сборку.gradle wrapperпосле клонирования на каждой сборке? По сути, это делает обертку бесполезной, поскольку весь смысл в том, что вам не нужно устанавливать Gradle локально для сборки проекта !Я хотел бы рекомендовать простой подход.
В README вашего проекта, документ, который требуется шаг установки, а именно:
Это работает с Gradle 2.4 или выше. Это создает оболочку без необходимости добавления выделенной задачи в «build.gradle».
С помощью этой опции игнорируйте (не регистрируйте) эти файлы / папки для контроля версий:
Основное преимущество заключается в том, что вам не нужно регистрировать загруженный файл в систему контроля версий. Это стоит один дополнительный шаг при установке. Я думаю, это того стоит.
источник
gradlew. @edio вам понадобится, чтобы скачать и использовать конкретную версию Gradle.Что такое "проект"?
Возможно, есть техническое определение этой идиомы, которое исключает сценарии сборки. Но если мы примем это определение, то мы должны сказать, что ваш «проект» - это не все, что вам нужно для версионности!
Но если мы говорим «ваш проект», это все, что вы сделали . Тогда мы можем сказать, что вы должны включить его и только его в VCS.
Это очень теоретически и, возможно, не практично в случае наших разработок. Поэтому мы изменили его на « ваш проект - это каждый файл (или папка), который вам нужно редактировать напрямую ».
«напрямую» означает «не косвенно», а «косвенно» означает редактирование другого файла, после чего эффект будет отражен в этом файле .
Таким образом, мы достигаем того же, что сказал OP (и сказано здесь ):
Да. Потому что вы их не создали. Таким образом, они не являются частью «вашего проекта» согласно второму определению.
Каков результат этих файлов:
build.gradle : да. Нам нужно отредактировать это. Наши работы должны быть версионными.
Примечание: нет разницы, где вы редактируете это. В среде вашего текстового редактора или в среде с графическим интерфейсом структуры проекта . В любом случае вы делаете это напрямую !
gradle-wrapper.properties : Да. Нам нужно как минимум определить версию Gradle в этом файле.
gradle-wrapper.jar и gradlew [.bat] : Я не создавал и не редактировал их ни в одной из своих разработок, до этого момента! Так что ответ «Нет». Если вы сделали это, ответ «Да» о вас на этой работе (и о том же файле, который вы редактировали).
Важное замечание о последнем случае это пользователь , который клонирует ваш репозиторий, необходимо выполнить эту команду на репо
<root-directory>для автоматического создания обертки файлов:$vи$distTypeопределяются из gradle-wrapper.properties :См. 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 , добавление
gradle-wrapper.jarв VCS ожидается, поскольку обеспечение доступности Gradle Wrapper для разработчиков является частью подхода Gradle:источник
Старый вопрос, свежий ответ. Если вы не обновляете gradle часто (большинство из нас этого не делают), лучше передать его в VCS. И главная причина для меня - увеличить скорость сборки на CI-сервере. В настоящее время большинство проектов создаются и устанавливаются CI-серверами, каждый раз с разными экземплярами сервера.
Если вы не подтвердите это, сервер CI будет загружать jar для каждой сборки, что значительно увеличивает время сборки. Есть и другие способы решения этой проблемы, но я считаю, что этот способ проще всего поддерживать.
источник