Відповіді:
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.як префікс.
Будь-які властивості цього файлу можна використовувати в будь-якому 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.