Хорошо, вот как мне удалось заставить его работать. Имея следующую структуру каталогов:
.
├── A
│ ├── C
│ │ └── build.gradle.kts
│ ├── D
│ │ └── build.gradle.kts
│ └── build.gradle.kts
├── B
│ ├── E
│ │ └── build.gradle.kts
│ ├── F
│ │ └── build.gradle.kts
│ └── build.gradle.kts
├── build.gradle.kts
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
└── settings.gradle.kts
settings.gradle.kts
имеет следующее содержимое:
rootProject.name = "multi-module-build"
include(":A")
include(":A:C")
include(":A:D")
include(":B")
include(":B:E")
include(":B:F")
Каждый build.gradle.kts
имеет задачу call
, которая печатает путь имени проект, например Внутри проекта C:
tasks.register("call") {
println(":A:C")
}
Внутри проекта A:
tasks.register("call") {
dependsOn(":A:C:call")
dependsOn(":A:D:call")
println(":A")
}
tasks["build"].dependsOn(":A:call")
tasks["build"].dependsOn(":A:call")
сообщает Gradle, что при вызове необходимо вызвать :A:call
. Два dependsOn
в определении call
для A
вызывают подпроект call
задач.
Существует аналогичная структура, доступная для B
.
При работе gradle build
на уровне root это вывод, который я получаю:
:A
:B
:A:C
:A:D
:B:E
:B:F
При запуске gradle build
внутри подпроекта A
я получаю:
:A
:A:C
:A:D
При запуске внутри :A:C
я не получаю никакого вывода, потому что я не указал, что задача C
build
должна зависеть от call
, но это легко сделать. Дайте мне знать, если это не сработает для вас. Я использовал Kotlin DSL для gradle, но вы можете свободно изменить его на вариант Groovy.