Gradle Kotlin DSL: проблемы с подпроектами и плагинами

Gradle 6.1.1

Я пытался преобразовать файлы Gradle моих проектов, используя Kotlin DSL, но пока не получилось. Все мои проекты являются многопроектными сборками на Java. Я следовал за примерами подпроекта плагина здесь

Это выглядит так:

plugins {
    idea
    eclipse
}

subprojects {
    apply(plugin = "java")

    dependencies {
       implementation("com.google.guava:guava:28.1-jre")
       //...
    }
}

Плагин java, кажется, не понят в подпроектах, и все строки «реализации» получают неразрешенную ссылку.

Всего 1 ответ


См. Документацию здесь https://docs.gradle.org/current/userguide/kotlin_dsl.html .

Типобезопасные средства доступа недоступны для элементов модели:

  • Плагины, применяемые с помощью метода apply (plugin = "id")
  • ...
 implementation()

Является ли такой безопасный тип доступа. Не типизированный способ выглядит следующим образом:

    apply(plugin = "java-library")
    dependencies {
        "api"("javax.measure:unit-api:1.0")
        "implementation"("tec.units:unit-ri:1.0.3")
    }

С отличным DSL, все методы разрешаются динамически (не типобезопасно), поэтому там это не имеет значения.

Это помогает понять, что файлы build.gradle.kts не являются чистыми файлами kotlin. Они бы выглядели намного ужаснее с большим количеством импорта наверху. Таким образом, среда выполнения gradle обрабатывает блок «buildscript» и «plugins» специальным образом. «Плагины» преобразуются в операторы импорта. Это не работает с методом apply (), который запускается позже, когда файл был скомпилирован. Вот почему блок плагинов нельзя использовать в других местах, это специальная конструкция, которая просто притворяется нормальным блоком кода. Чуть подробнее здесь https://docs.gradle.org/current/dsl/org.gradle.plugin.use.PluginDependenciesSpec.html

Совет

С точки зрения проектирования модулей, я бы обычно рекомендовал, чтобы корневой модуль в многомодульной сборке оставался независимым от того, что делают подмодули, даже если многие люди используют блок подпроектов, как это делает ваш пример. Пусть каждый файл сборки подмодулей будет таким же полным, как если бы это был независимый проект Gradle, чтобы читатели не читали 2 файла, чтобы получить полную картину.

Существуют более четкие способы совместного использования конфигурации между подпроектами.

Блок подпроектов в корневом файле лучше всего использовать для добавления дополнительных задач, если они необходимы из корневого каталога проекта, IMO. Не вводить плагины или конфигурацию.


Есть идеи?

10000