openlang

После перехода на Kotlin DSL подпроекты не видят implementation

Переношу старую многопроектную сборку с Groovy DSL на Kotlin DSL. В корневом build.gradle был такой блок.

subprojects {
    apply plugin: 'java-library'
    repositories { mavenCentral() }
}

Корень переведён механически.

subprojects {
    apply(plugin = "java-library")
    repositories { mavenCentral() }
}

Дальше по порядку.

Корневой скрипт компилируется. Здесь претензий нет.

В подпроекте core/build.gradle.kts строка implementation(project(":util")) внутри dependencies останавливает компиляцию скрипта с неразрешённой ссылкой на implementation. Под Groovy та же строка работала.

Необъяснимый случай - третий. Стоит добавить plugins { id("java-library") } в начало того же файла, и ошибка пропадает, хотя корень и так применял этот плагин. Плагин тот же, проект тот же, почему пропадают только аксессоры? И неужели задуманное решение - повторять блок plugins в каждом подпроекте?

Переведено с английскогоПоказать оригинал

Разговор продолжается 2

Следуя доводам
  1. Ссылка на ответ

    Блок plugins, да. Только не копируйте его в каждый подпроект.

    Аксессоры Gradle строит по тому, что применил блок plugins этого самого скрипта. Плагин, пришедший любым другим путём, через apply(plugin = ...) или корневой блок subprojects, во время выполнения работает нормально, а аксессоров не получает. В документации перечислены ровно эти случаи.

    Удалите блок subprojects и положите в buildSrc один convention-плагин.

    // buildSrc/build.gradle.kts
    plugins {
        `kotlin-dsl`
    }
    repositories { gradlePluginPortal() }
    
    // buildSrc/src/main/kotlin/java-conventions.gradle.kts
    plugins {
        `java-library`
    }
    repositories { mavenCentral() }
    
    // core/build.gradle.kts
    plugins {
        id("java-conventions")
    }
    dependencies {
        implementation(project(":util"))
    }

    Блок plugins подпроекта применяет convention-плагин, тот подтягивает java-library, и аксессоры приходят вместе с ним.

    Переведено с английскогоПоказать оригинал
  2. Ссылка на ответ

    Как конечное состояние - согласен. Но пока часть подпроектов ещё получает плагин из корневого блока, в Kotlin DSL есть запасной путь без аксессоров.

    dependencies {
        "implementation"(project(":util"))
    }
    configure<JavaPluginExtension> {
        toolchain.languageVersion.set(JavaLanguageVersion.of(17))
    }

    Читается хуже, и опечатка в строке всплывёт только при запуске сборки (неизвестное имя конфигурации падает в этот момент, а не при компиляции скрипта). На время миграции такая цена приемлема, после неё держать это не стоит.

    Переведено с английскогоПоказать оригинал

Другие стороны того же вопроса

  1. tryEval пропустил нарочно сломанный пакет

    Есть у меня небольшой обход оверлея, который оборачивает каждый пакет в builtins.tryEval и перечисляет упавшие. Он сообщил, ч…

    Ответы 4nix
  2. Ключи for_each - это адреса, а не ярлыки

    Ключ for_each - не ярлык. Это половина адреса ресурса, terraform_data.queue["prod-orders"], и состояние хранит объект именно…

    Ответы 6hcl
  3. Запуск потребителя по событию остановки

    Пришёл вопрос про правило супервизора, которое считает остановленный процесс завершённым, и маленький пример сразу показывает…

    Ответы 17bashpython