Даже если мы вызываем задачу для конкретного подпроекта, то все-равно выполняется конфигурация для всех проектов многопроектной сборки. Это сделано для обеспечения гибкости в доступе и в изменяемости проектной модели из любой задачи. Факт, что этап выполнения не наступает пока не будут считаны настройки всех задач сборки, даже если задача которую мы вызываем находится первой в файле сборки, означает, что выполнение задачи будет обеспечено точной и полной настройкой текущей сборки проекта.
"Конфигурация по потребности"
Режим, который планируется быть включенным по умолчанию в будущем, при котором, при вызове задачи будут считываться только настройки задач, от которых находится в зависимости вызываемая задача. Это позволяет значительно уменьшить время выполнения огромных многомодульных проектов.
В этом режиме сборка происходит по следующей схеме:
- Настройки коренного проекта всегда считываются. Благодаря этому поддерживается общая настройка: блоки скриптов allprojects or subprojects.
- Если билд выполняется из директории какого-то подпроекта, то он тоже принимает участие в настройке, но только если в билде не указана конкретная задача или же задача из его сборки.
- Происходит настройка проектов из дерева зависимостей вызываемой задачи.
- Происходит настройка проектов из зависимостей по иерархическим путям (
someTask.dependsOn(":someOtherProject:someOtherTask").
- Происходит настройка проектов из зависимостей по иерархическим путям упомянутым через командную строку или Tooling API.
Сейчас эта "фича в инкубаторе" может включаться через:
gradle.properties( build dir | user home | command line -Dsome.property ):
org.gradle.configureondemand=true
Межпроектная настройка и впрыскивание настроек (cross project configuration & configuration injection)
Можно получить доступ до любого проекта из любого другого файла сборки, если они находятся в одном многомодульном проекте. Project имеет метод project, который принимает путь, а возвращает Project экземпляр, указанного по пути проекта.
Closure cl = { task -> println "I'm $task.project.name" }
task('hello').doLast(cl)
project(':bluewhale') {
task('hello').doLast(cl)
}
Возможность обслуживания многопроектной сборки одним файлом сборки
Вовсе не обязательно под каждый модуль держать отдельный файл сборки. Все/или часть можно решить в одном коренном благодаря allprojects and subprojects.
Build layout:
water/
build.gradle
settings.gradle
bluewhale/
krill/
settings.gradle:
include 'bluewhale', 'krill'
build.gradle
allprojects {
task hello {
doLast { task ->
println "I'm $task.project.name"
}
}
}
subprojects {
hello {
doLast {
println "- I depend on water"
}
}
}
project(':bluewhale').hello {
doLast {
println "- I'm the largest animal that has ever lived on this planet."
}
}
$ gradle -q hello
> gradle -q hello
I'm water
I'm bluewhale
- I depend on water
- I'm the largest animal that has ever lived on this planet.
I'm krill
- I depend on water
Также есть возможность
фильтровать подпроекты. Например метод Project.configure ожидает список и применяет конфигурации в проекты из этого списка:
configure(subprojects.findAll {it.name != 'tropicalFish'}) {
hello {
doLast {
println '- I love to spend time in the arctic waters.'
}
}
}
tropicalFish/build.gradle(в остальных билдфайлах ставим тру):
ext.arctic = false
build.gradle
...
subprojects {
hello {
doLast {println "- I depend on water"}
afterEvaluate { Project project ->
if (project.arctic) { doLast {
println '- I love to spend time in the arctic waters.' }
}
}
}
}
Фишка в том, что замыкание, которое мы определяем, оценивается после оценки скриптов сборки подпроектов.
Устройство логики сборки
- Если логика повторяется больше чем в одном замыкании таски, нужно эту логику выносить в метод(он попадает в инстанцию Project).
- Если логика повторяется в подпроектах, ее нужно выносить в метод отцовского проекта.
- Если логика вычурная, чтобы поместиться в одном методе, тогда создаем целый. Такой класс размещается в специализированной директории(./buildSrc), и Gradle его компилирует и добавляет в класспаз срипта сборки.
Унаследованные свойства и методы
В подпроектах видны свойства и методы отцовского.
build.gradle:
// Define an extra property
ext.srcDirName = 'src/java'
// Define a method
def getSrcDir(project) {
return project.file(srcDirName)
}
child/build.gradle
task show {
doLast {
// Use inherited property
println 'srcDirName: ' + srcDirName
// Use inherited method
File srcDir = getSrcDir(project)
println 'srcDir: ' + rootProject.relativePath(srcDir)
}
}
Впрыснутые настройки
build.gradle
subprojects {
// Define a new property
ext.srcDirName = 'src/java'
// Define a method using a closure as the method body
ext.srcDir = { file(srcDirName) }
// Define a task
task show {
doLast {
println 'project: ' + project.path
println 'srcDirName: ' + srcDirName
File srcDir = srcDir()
println 'srcDir: ' + rootProject.relativePath(srcDir)
}
}
}
// Inject special case configuration into a particular project
project(':child2') {
ext.srcDirName = "$srcDirName/legacy"
}
child1/build.gradle
// Use injected property and method. Here, we override the injected value
srcDirName = 'java'
def dir = srcDir()
Настройка с использованием внешних скриптов сборки
build.gradle
apply from: 'other.gradle'
other.gradle
println "configuring $project"
task hello {
doLast {
println 'hello from other script'
}
}
Сборка исходников в buildSrc
Gradle при запуске проверяет нет ли в проекте директории buildSrc, если есть - то все что там, компилируется, тестируется и добавляется в класспаз. Это место для кастомный тасок и плагинов. В многомодульном проекте такая папка может быть только одна.
По умолчанию применяется всегд следующий Default buildSrc build script, добавляя в папку buildSrc скрипты, мы расширяем его:
apply plugin: 'groovy'
dependencies {
compile gradleApi()
compile localGroovy()
}
Выполнение другого файла сборки Gradle из текущего.
Для этого существует таска GradleBuild
build.gradle:
task build(type: GradleBuild) {
buildFile = 'other.gradle'
tasks = ['hello']
}
other.gradle:
task hello {
doLast {
println "hello from the other build."
}
}
> gradle -q build
hello from the other build.
Внешние зависимости для скрипта сборки
Делается это через метод buildscript.
build.gradle
import org.apache.commons.codec.binary.Base64
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath group: 'commons-codec', name: 'commons-codec', version: '1.2'
}
}
task encode {
doLast {
def byte[] encodedString = new Base64().encode('hello world\n'.getBytes())
println new String(encodedString)
}
}
> gradle -q encode
aGVsbG8gd29ybGQK
В многомодульном проекте зависимости объявлены в родительском проекте доступны во всех сборках подпроектов.
Зависимостями скриптов сборки могут быть и плагины.
Правила выполнения для многопроектной сборки
- Если с отцовской директории, то проходится по всем подпроектам собирая настройки и запускает после этого указанную таску в тех проектах, в которых она настроена.
- Если с конкретного подпроекта, то подымается к отцовскому файлу сборки, собираем настройки по всем проектам, но запускается таска только в текущем подпроекте(директории) и в подпроектах, который дочерние к текущему(поддиректории к текущей).
Выполнение задач по абсолютному пути
Если мы находимся в какой-то дочерней директории/проекте, но нам нужно выполнить задачу из ряда других подпроектов, то нам не обязательно покидать текущую директорию -- мы можем указать абсолютные путь интересующих нас задач в проектах.
> gradle -q :hello :krill:hello hello
: -- обращение к рут-проекту
:hello -- это задача в коренном проете
:krill:hello -- вызов задачи в подпректе krill
hello -- вызов задачи в текущей директории
Зависимости
Есть зависимости времени настраивания и есть зависимости времени выполнения
По умолчанию задачи выполняются после сортировки в алфавитном порядке абсолютных путей задач.
Порядок выполнения задач, кроме алфавитного порядка, можно предопределять через свойство dependsOn:
task consume(dependsOn: ':producer:produce') {
doLast {
println("Consuming message: ${rootProject.producerMessage}")
}
}
Иногда когда нужно указать порядок не только на этапе выполнения, но и на этапе оценки/считывания настроек, для этого evaluationDependsOn(это
зависимости времени настраивания).
evaluationDependsOn(':producer')
def message = rootProject.producerMessage
task consume {
doLast {
println("Consuming message: " + message)
}
}
