Gradle Kotlin DSL: проблемы с подпроектами и плагинами - PullRequest
Новая
       6

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

3 голосов
/ 10 февраля 2020

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 Ответ

1 голос
/ 10 февраля 2020

См. Документацию здесь 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")
    }

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

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

Советы

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

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

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

...