Правильная структура многомодульных модулей Gradle с IntelliJ IDEA

У меня есть проект Котлин, который состоит из трех модулей:

Core < Service < Web 

Структура:

 build.gradle core/ build.gradle service/ build.gradle web/ build.gradle 

Структура корневого файла build.gradle :

 buildscript { ext.kotlin_version = '1.1.60' repositories { mavenCentral() jcenter() } dependencies { classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version" } } subprojects { apply plugin: 'kotlin' apply plugin: 'jacoco' compileKotlin { kotlinOptions.jvmTarget = '1.8' } repositories { mavenCentral() jcenter() } } 

Отдельные файлы сборки выглядят как (для core ):

 dependencies { // Kotlin compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version" ... } 

И для service (обратите внимание, что единственная разница зависит от проекта):

 dependencies { compile project (':core') // Kotlin compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version" ... } 

Есть несколько оптимизаций, которые я хотел бы сделать, но я все еще изучаю Gradle и не могу найти правильный способ реорганизации. У меня проблемы:

  1. Я не могу создавать service или web индивидуально, поскольку они жалуются на то, что не могут найти свои зависимые подпроекты. ( gradle build в каталоге service/ .)

  2. Как определить зависимость Kotlin stdlib-jre8 на корневом уровне, поэтому он не дублируется в моих трех файлах сборки?

  3. Как мои задачи подпроекта / buildscript корневого файла сборки используют одни и те же определения репозитория, поэтому мне не нужно mavenCentral()/jcenter() определять mavenCentral()/jcenter() ?

В основном, эта структура построения, которую я создал, была собрана вместе с помощью некоторых экспериментов / веб-ресурсов и , в основном, работает , но я хотел бы получить некоторые рекомендации по ее правильному пути, такие как (1) это следует за хорошими методами Gradle и ( 2) все еще хорошо работает через авто-импорт в IDEA.

  1. Если вы хотите запустить сборку модуля, вы можете сделать это: gradle :web:build
  2. Точно так же, как вы добавляете репозитории в предложение subprojects , вы можете добавить туда блок dependencies . Убедитесь, что там находятся только общие зависимости. Например, compile project(':core') должен находиться только в соответствующем проекте. Это нормально, что несколько блоков dependency . Тем не менее, обычно чаще головная боль использует предложение subproject . Поскольку, если зависимости меняются для одного из модулей, вы вынуждены обновлять их для всех
  3. Что касается определений repository , они очень разные. Один из блоков buildscript используется самим Gradle, чтобы найти плагины и другие требования к предварительной сборке. Один из подмодулей используется для нахождения зависимостей исходного кода в данном модуле. Как упоминалось в предыдущем пункте, легче управлять, когда размещены на соответствующих скриптах сборки модуля.

Обновить:

Если вы хотите сохранить одну и ту же версию для всех модулей, переменные, определенные в ext в buildscript, также должны быть доступны из подмодулей: ext.kotlin_version = '1.1.60' и если у вас есть несколько, вы можете добавить их как:

 ext { kotlin_version = '1.1.60' junit_version = '4.12' } 

Кроме того, если вы хотите использовать код между модулями, вы всегда можете извлечь его в файл gradle и загрузить его там, где необходимо, используя: apply file: "$rootDir/path/to/script.gradle"

Что касается № 3, я приведу вам практический пример.

Google имеет свой собственный репозиторий maven, который содержит все зависимости для модуля android. Если у вас есть проект, который содержит как серверный модуль, так и модуль Android, вам может не понадобиться серверная сторона для поиска зависимостей от репозитория Gradle artefact (artefact – это имя зависимости jar).

Что касается репозиториев buildscript , в вашем случае вы загружаете только зависимость от mavenCentral() pre-build), которая находится на mavenCentral() поэтому вы можете удалить jcenter() здесь.