Когда использовать gradle.properties или settings.gradle?

91

Сборка gradle состоит из трех файлов

  • build.gradle который определяет сценарии конфигурации сборки
  • gradle.properties
  • settings.gradle

Вопросы

  • В чем разница между settings.gradle& gradle.properties?
  • Когда следует вводить настройки settings.gradlevs. gradle.properties?
java gradle build build-system амс
источник

Ответы:

85

settings.gradle

settings.gradleФайл является Groovy скрипт, так же , как build.gradleфайл. В settings.gradleкаждой сборке будет выполняться только один сценарий (по сравнению с несколькими build.gradleсценариями в сборках с несколькими проектами). settings.gradleСкрипт будет выполняться до любого build.gradleсценария , и даже до того , как Projectэкземпляры создаются. Следовательно, он оценивается относительно Settingsобъекта. С помощью этого Settingsобъекта вы можете добавлять подпроекты в свою сборку, изменять параметры из командной строки ( StartParameter) и получать доступ к Gradleобъекту для регистрации обработчиков жизненного цикла. Как следствие, используйте, settings.gradleесли ваши настройки связаны со сборкой, а не обязательно с проектом или требуют логики перед включением возможных подпроектов.

gradle.properties

gradle.propertiesФайл представляет собой простой Java - Propertiesфайл , который только получает особую роль, будучи автоматически входят в рамки Projectобъекта ( в виде так называемой «Свойства проекта»). Это простое хранилище ключей и значений, которое позволяет использовать только строковые значения (поэтому вам нужно самостоятельно разбивать списки или массивы). Вы можете разместить gradle.propertiesфайлы в следующих местах:

  • непосредственно в каталоге проекта (для значений, связанных с проектом)
  • в домашнем .gradleкаталоге пользователя (для значений, связанных с пользователем или средой)
Лукас Кёрфер
источник
63

В многомодульном проекте есть один главный модуль и множество подмодулей. Он имеет такую ​​раскладку:

(root)
  +- settings.gradle       
  +- build.gradle          # optional (commonly present)
  +- gradle.properties     # optional
  +-- buildSrc/            # optional
  |     +- build.gradle    
  |     +-- src/...
  +-- my-gradle-stuff/     # optional
  |     +- utils.gradle    # optional
  +-- sub-a/
  |     +- build.gradle
  |     +- src/
  +-- sub-b/
        +- build.gradle
        +- src/

подмодули также могут располагаться глубже во вложенных папках, но без изменения кода в settings.gradle их имя будет включать имя таких папок.

settings.gradle

Основная роль settings.gradle состоит в том, чтобы определить все включенные подмодули и пометить корень каталога дерева модулей, чтобы вы могли иметь только один settings.gradleфайл в многомодульном проекте.

rootProject.name = 'project-x'

include 'sub-a', 'sub-b'

Файл настроек также написан на Groovy, и поиск подмодулей можно настроить.

build.gradle

На каждый модуль приходится один такой файл, он содержит логику сборки для этого модуля.

В build.gradleфайле основного модуля вы можете использовать allprojects {}или subprojects {}для определения настроек для всех остальных модулей.

В build.gradleфайле подмодулей вы можете использовать, compile project(':sub-a')чтобы один подмодуль зависел от другого.

gradle.properties

Это необязательно, его основная цель - предоставить параметры запуска для использования самого Gradle, например

org.gradle.jvmargs=-Xmx=... -Dfile.encoding=UTF-8 ...
org.gradle.configureondemand=true

Эти значения могут быть переопределены файлом USER_HOME/.gradle/gradle.propertiesи переопределены аргументами командной строки gradle. Также можно установить переменные среды для сборки в этом файле, используя systemProp.префикс as.

Любое свойство в этом файле можно использовать в любом build.gradle, поэтому некоторые проекты также помещают информацию о версии или выпуске зависимостей gradle.properties, но это, вероятно, является злоупотреблением этим файлом.

мой-градиент-материал / utils.gradle

(Возможно любое имя папки или файла.) Вы можете определить дополнительные пользовательские файлы Gradle для повторного использования определений и включить их в другие файлы Gradle с помощью

apply from: "$rootDir/gradle/utils.gradle"

другие места для размещения этого могут быть src/gradleилиsrc/build/gradle

buildSrc / ...

Эта папка особенная, она как отдельный проект gradle. Он создается до того, как делать что-либо еще, и может предоставлять функцию для использования в любом другом файле gradle. По техническим причинам поддержка IDE ссылок на эту папку работает намного лучше, чем любой другой способ извлечения общего кода из нескольких build.gradleфайлов в отдельное место.

Вы можете определить сложную настраиваемую логику сборки в java, groovy или kotlin вместо написания и развертывания плагина. Это также полезно для модульного тестирования вашего пользовательского кода сборки, так как вы можете иметь модульные тесты. Структура исходных папок buildSrcможет быть адаптирована как для любого проекта java / groovy / kotlin.

ткрузе
источник