большое спасибо! пойду изучать

Кстати, ещё один минус зоопарка в гредл скриптах у разных проектов: некоторые авторы либ даже представить себе не могут, что кому-то кроме них надо будет собрать либу, поэтому для этого иногда приходится идти и править билдскрипты, чтобы убрать публикацию, требующую логины-пароли.

Чувствую твою боль - мне в одном проекте подписывание приходится sed'ом отрезать

Ну это частный случай "не работает без окружения". На любую стандартизацию найдётся проект, который на что-то завяжется.
Например, Android SDK 🌚

Справедливости ради, проекты, завязанные на Android SDK, рациональной зависимостью её вряд ли смогут потянуть))

Хотя да, я до сих пор не понимаю, почему бы не опубликовать android.jar для разных сдк в гугловую мавен репу, к примеру

Котлиновские плагины могут всё, что им нужно, сами стянуть и развернуть, будь то тулчейн LLVM+clang, ноду с npm и вебпаком или что-то другое. А гугель как обычно.

Можно это делать эстетичнее и экстравагантнее: добавить в init.gradle.kts блок, который отключит эти самые sign и прочее у «вражеских» проектов

Есть общий класс, для которого написан мок, который также общий. И было бы удобно не копировать мок по всем модулям а заюзать из common.

Чёт я себя совсем дурачком чувствую.

Хочу завести себе convention plugins для нескольких типов модулей. Допустим, для модуля приложения и модуля библиотеки.
У AGP для этих целей есть плагины com.android.application и com.android.library соответственно.
Оба плагина регистрируют экстеншн android, соответстввенно, типа AppExension и LibraryExtension.
Оба этих типа наследуются от BaseExtension.
Часть конфига у меня общая и для либ, и для аппов, часть специфичная.

Я тут попытался сделать конвеншн плагин myproject.app, который применяет com.android.application и другой конвеншн плагин myproject.common. Но в myproject.common я, не применяя никаких плагинов (пушта это и для либ, и для апп) не могу, получается, получить доступ к классам BaseExtension, AppExtension, LibraryExtension.

Можно, конечно, не писать коммон плагин, а завести себе просто

fun Project.configureCommonAndroid() {
    val android = extensions.getByType(AppExtension::class) ?:
        extensions.getByType(LibraryExtension::class)
    android?.apply {
        ...
    }
}

и вызывать эту фигню вместо эпплая коммон конвеншн плагина.
Есть другие варианты?

Возможно, глупость предложу (т.к. android не запускал ни разу), но можно ли применить test-fixtures (штатный механизм Gradle), или, например, вынести нужный общий класс в свой Gradle модуль?

Читал про test-fixtures, но как я понял в андроид проектах это не работает.

Перечитал 2 раза.
Похоже, ответ в том, чтобы в myproject.common.gradle.kts плагин (к его `build.gradle.kts`) добавить зависимость на android плагин.

Например, так: https://github.com/cbeust/testng/blob/4fac3bcea2fc968d8450866c1ef60f7035122b06/build-logic/jvm/build.gradle.kts#L12-L13

—

Либо, можно делать несколько своих myproject.android-lib — у него зависимость на android.library.  myproject.android-app — у него зависимость на android.app ну и тогда у они смогут норм обращаться к нужным extension’ам (или добавлять свои extension’ы)

А без зависимости именно на артифакт *.gradle.plugin кина не будет? А то у AGP его нет :)

А, точно. Ну, там, значит, зависимость простая. Не суть важно )

Хотя, конечно, я думал, что обычно добавляют substitution, чтобы объявлять через id(«…android») version «…»

Я обычно и добавляю в корневой settings.gradle, но щас я пытаюсь сделать конвеншн-плагины и прям шагаю по граблям.

Блин, где-то видел отличный пример сетапа с композитными билдами и конвеншн плагинам для андроида, но теперь найти его не могу. Кажется, сам я эту херню не осилю.

Впрочем, я уже на грани того, чтобы бросить это и продолжать копипастить по старинке.

Нельзя столько времени тратить на грёбаные билд-скрипты.