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

У градиловой сборки есть три файла

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

Вопросы

  • Каковы различия между settings.gradle & gradle.properties?
  • Когда нужно устанавливать настройки в settings.gradle vs. gradle.properties?

ОТВЕТЫ

Ответ 1

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 (для user- или значений, связанных с окружающей средой)

Ответ 2

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

(root)
  +- settings.gradle       
  +- build.gradle          # optional (commonly present)
  +- gradle.properties     # optional
  +-- buildSrc/            # optional
  |     +- build.gradle    # optional
  |     +-- src/           # optional
  |     +-- test/          # optional
  +-- gradle/              # 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 основного модуля main module вы можете использовать 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. в качестве префикса.

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

Gradle/utils.gradle

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

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

buildSrc/...

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