Ответы:
settings.gradlesettings.gradleФайл является Groovy скрипт, так же , как build.gradleфайл. В settings.gradleкаждой сборке будет выполняться только один сценарий (по сравнению с несколькими build.gradleсценариями в сборках с несколькими проектами). settings.gradleСкрипт будет выполняться до любого build.gradleсценария , и даже до того , как Projectэкземпляры создаются. Следовательно, он оценивается относительно Settingsобъекта. С помощью этого Settingsобъекта вы можете добавлять подпроекты в свою сборку, изменять параметры из командной строки ( StartParameter) и получать доступ к Gradleобъекту для регистрации обработчиков жизненного цикла. Как следствие, используйте, settings.gradleесли ваши настройки связаны со сборкой, а не обязательно с проектом или требуют логики перед включением возможных подпроектов.
gradle.propertiesgradle.propertiesФайл представляет собой простой Java - Propertiesфайл , который только получает особую роль, будучи автоматически входят в рамки Projectобъекта ( в виде так называемой «Свойства проекта»). Это простое хранилище ключей и значений, которое позволяет использовать только строковые значения (поэтому вам нужно самостоятельно разбивать списки или массивы). Вы можете разместить gradle.propertiesфайлы в следующих местах:
.gradleкаталоге пользователя (для значений, связанных с пользователем или средой)В многомодульном проекте есть один главный модуль и множество подмодулей. Он имеет такую раскладку:
(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файл в многомодульном проекте.
rootProject.name = 'project-x'
include 'sub-a', 'sub-b'
Файл настроек также написан на Groovy, и поиск подмодулей можно настроить.
На каждый модуль приходится один такой файл, он содержит логику сборки для этого модуля.
В build.gradleфайле основного модуля вы можете использовать allprojects {}или subprojects {}для определения настроек для всех остальных модулей.
В build.gradleфайле подмодулей вы можете использовать, compile project(':sub-a')чтобы один подмодуль зависел от другого.
Это необязательно, его основная цель - предоставить параметры запуска для использования самого 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, но это, вероятно, является злоупотреблением этим файлом.
(Возможно любое имя папки или файла.) Вы можете определить дополнительные пользовательские файлы Gradle для повторного использования определений и включить их в другие файлы Gradle с помощью
apply from: "$rootDir/gradle/utils.gradle"
другие места для размещения этого могут быть src/gradleилиsrc/build/gradle
Эта папка особенная, она как отдельный проект gradle. Он создается до того, как делать что-либо еще, и может предоставлять функцию для использования в любом другом файле gradle. По техническим причинам поддержка IDE ссылок на эту папку работает намного лучше, чем любой другой способ извлечения общего кода из нескольких build.gradleфайлов в отдельное место.
Вы можете определить сложную настраиваемую логику сборки в java, groovy или kotlin вместо написания и развертывания плагина. Это также полезно для модульного тестирования вашего пользовательского кода сборки, так как вы можете иметь модульные тесты. Структура исходных папок buildSrcможет быть адаптирована как для любого проекта java / groovy / kotlin.