Я уже некоторое время использую Gradle, но никогда не углублялся в его многие функции и возможности, но на днях я решил разделить свой Java-проект на два модуля для упрощения тестирования и обслуживания. После того, как я закончил, я начал читать о Авторские мультипроекты и одну из более новых концепций Gradle под названием Составные сборки . Затем я провел большую часть дня, пытаясь применить (как мне показалось, я понял) эти знания, чтобы сделать мой проект модульным. Можно с уверенностью предположить, что я не добился успеха, и теперь я прошу помощи в понимании этих концепций и их применения.
Теоретическое рабочее пространство
Давайте представим, что у нас есть следующая структура каталогов:
toolbox
|
├── first-tool
| └── build.gradle
|
├── second-tool
| └── build.gradle
|
├── build.gradle
└── settings.gradle
А это проекты внутри корневого каталога:
Root project 'toolbox'
+--- Project ':first-tool'
\--- Project ':second-tool'
Давайте сделаем проект first-tool введем внешнюю зависимость org.master-toolbox:some.other.tool, от которой зависит второй набор инструментов, но он не реализует сам себя:
default - Configuration for default artifacts.
+--- org.master-toolbox:some.other.tool:1.0
| +--- ...
\--- io.toolbox:first-tool
Это соответствующие файлы Gradle:
settings.gradle
rootProject.name = 'toolbox'
include 'first-tool', 'second-tool'
toolbox.build.gradle
allprojects {
apply plugin: 'java-library'
group = "io.toolbox"
repositories {
jcenter()
}
}
первый-tool.build.gradle
dependencies {
// This is an external dependency that is resolved through jcentral
implements 'org.master-toolbox:some.other.tool:1.0'
}
второй-tool.build.gradle
dependencies {
// Try to implement first-tool build to inherit dependencies
implementation 'io.toolbox:first-tool'
}
Выше приведена хорошая структура проекта, как показано выше, но она не будет работать полностью, потому что second-tool не найдет first-tool и что-то похожее на следующую ошибку появится в нашей консоли:
> Could not resolve all files for configuration ':second-tool:compileClasspath'.
> Could not find io.toolbox:first-tool:.
Required by:
project :second-tool
Теперь, насколько я понимаю, именно здесь предполагается, что составные сборки будут загружены и сохранят день, позволив нам включать целые сборки. Ну, это звучит здорово, давайте просто обновимся settings.gradle:
rootProject.name = 'toolbox'
includeBuild `first-tool`
include 'second-tool'
Теперь проект правильно собирается и компилируется, все хорошо, верно? Ну, не совсем так, поскольку использование ключевого слова includeBuild в нашем settings.gradle first-tool больше не наследует свойства от toolbox и по существу перестало быть подпроектом toolbox.
Цель проекта
Скорее всего, я неправильно понимаю всю концепцию составных сборок или просто делаю глупые ошибки. В любом случае, я хотел бы знать, есть ли какой-либо способ иметь иерархическую многопроектную структуру с подпроектами, которые взаимозависимы друг от друга?
В нынешнем виде я должен выбрать между:
- обычная многопроектная сборка, где все аккуратно и организовано, и все мои подпроекты имеют одинаковые определения из топового проекта.
- составная сборка, где я могу свободно создавать зависимости между проектами.
Было бы замечательно, если бы было возможно иметь основной build.gradle, который находится в корневом каталоге верхнего проекта и определяет общие плагины, репозитории, группы и т. Д. Для всей иерархии. Тогда другие проекты будут иметь свои собственные файлы build.gradle, которые придадут им уникальные свойства, но выполнят свои задачи из верхнего проекта.
Я уже прочитал официальную документацию по этому вопросу, поэтому я ищу более конкретные объяснения и указания о том, как достичь этой конкретной цели.