Комментарии 4
Смелые ребята, мне тоже нравится Kotlin DSL, но maven - надежнее))
Я правильно понял, что вы копируете код, создающий варианты в каждый модуль вручную? Это все еще выглядит слишком трудоемко - что, например, если вы захотите конфигурировать еще какой-нибудь параметр варианта? Если вы хотите применять один и тот же набор вариантов для всех модулей, то у Gradle есть намного более простое и идиоматическое решение для этой задачи - precompiled script plugins, также известные как convention plugins. Можно написать один файл в buildSrc, например my-android-conventions.gradle.kts, в который и поместить всё конфигурирование вариантов, в виде DSL, как у вас это было изначально:
plugins {
id("com.android.application") // без версии
}
android {
buildTypes{
getByName("debug"){
applicationIdSuffix = ".debug"
}
// ...
}
// ...
}
Единственный нюанс - для того, чтобы иметь возможность применять Android-плагин из вашего плагина, нужно добавить его в implementation classpath buildSrc, написав в buildSrc/build.gradle.kts:
repositories {
google()
}
dependencies {
implementation("com.android.tools.build:gradle:7.2.0")
}
После этого в модулях достаточно просто применить этот плагин:
plugins {
id("my-android-conventions")
}
Добрый день. Спасибо за комментарий.
Мы в модулях пишем код создания вариантов на абстрактном уровне, без деталей. При добавления нового варианта достаточно создать реализацию интерфейса и добавить в метод getAll.
Предложенный вами вариант вполне подходит для того, чтобы сделать код еще красивее и компактнее. Данная статья акцентирована на ООП подходе создания вариантов, вынесении явных обозначений билдов из gradle файла, поэтому мы не стали писать про вспомогательные действия.
если нам понадобится сменить путь keystore, suffix или что-то еще, мы сделаем это всего один раз
А что мешает на Groovy так же вынести отдельно эти значения?
Объектно-ориентированный Gradle. Настраиваем Build types в Android, используя Kotlin DSL