Вы про AI-инструменты для автокомплита в IDE? Они решают немного другую проблему - предлагают дополнить код в уже существующем файле. File Templates (не путать с Live Templates) - это про возможность сгенерировать в пару кликов дерево из директорий и файлов с предзаполненным шаблонным кодом. В следующей части как раз буду разбирать на примере, будет более понятно на что инструмент способен и для чего нужен :)
Согласен, при публикации плагинов FQN - это must have. Вместе с тем, для плагинов, которые используются только в рамках конкретного проекта , если FQN длинный, такой нейминг может трудно запоминаться или быть не совсем удобным в использовании.
По второму пункту - да, можно располагать -gradle.kts файлы и в подпапках, а не в корневой папке, но важно не забыть при использовании плагина дописывать путь через точку где он лежит, т.е. если у файла такое расположение - io/github/dmitriy1892/conventionplugins/android.base.config.gradle.kts , то при использовании в plugins-блоке в build.gradle.kts -файлах нужно указывать так:
Скорее всего, из-за такого не совсем очевидного момента (и возможных неудобств в использовании, если запихать файл слишком глубоко в директории), подход с хранением -gradle.kts файлов в не-рутовых папках и не возымел широкого распространения :)
buildSrc - это тоже вариант, но у него есть свои ограничения и недостатки в части кэширования сборки и пр. :)
Возможно, это поможет с подключением: при использовании композитных сборок (composite builds) вместо buildSrc самый важный момент - это правильно прописать подключение модуля с плагинами в основной проект. В файле settings.gradle.kts основного проекта нужно указывать не include(":convention-plugins:base"), а includeBuild("convention-plugins/base") - без двоеточий, как обычный путь до директории, где лежит build.gradle.kts-файл модуля с плагинами (довольно часто встречающаяся ошибка)
Судя по логу ошибки, в модуле :plugins:base есть sourceSet test (папка test), для которого не задан android-плагин...Удалите и попробуйте синхронизировать проект. Если проект выложен в публичный репозиторий, было бы проще разобраться
Хорошая статья, было интересно почитать. Я бы еще обозначил пару важных моментов:
1. В реализации функции `Di.instance()` было бы неплохо бросать более понятную ошибку, что класс такой-то не зарегистрирован в графе. Ну и в случае миграции ключей зависимостей с простых `KClass` на составные (по типу как в Koin), может появиться еще одна ошибка о том, что возвращаемый тип не совпадает;
2. Стоит отметить, что c `Map`-ой фабрик не получится сделать проверку графа зависимостей во время компиляции и есть риск упасть в рантайме с такой реализацией DI.
Тем временем, вышла вторая часть, где на примере описывается работа инструмента :)
Вы про AI-инструменты для автокомплита в IDE? Они решают немного другую проблему - предлагают дополнить код в уже существующем файле. File Templates (не путать с Live Templates) - это про возможность сгенерировать в пару кликов дерево из директорий и файлов с предзаполненным шаблонным кодом. В следующей части как раз буду разбирать на примере, будет более понятно на что инструмент способен и для чего нужен :)
Спасибо за дельный комментарий!
Согласен, при публикации плагинов FQN - это must have.
Вместе с тем, для плагинов, которые используются только в рамках конкретного проекта , если FQN длинный, такой нейминг может трудно запоминаться или быть не совсем удобным в использовании.
По второму пункту - да, можно располагать
-gradle.ktsфайлы и в подпапках, а не в корневой папке, но важно не забыть при использовании плагина дописывать путь через точку где он лежит, т.е. если у файла такое расположение -io/github/dmitriy1892/conventionplugins/android.base.config.gradle.kts, то при использовании вplugins-блоке вbuild.gradle.kts-файлах нужно указывать так:Скорее всего, из-за такого не совсем очевидного момента (и возможных неудобств в использовании, если запихать файл слишком глубоко в директории), подход с хранением
-gradle.ktsфайлов в не-рутовых папках и не возымел широкого распространения :)Как понимаю, этот extension помог решить проблему? :)
Спасибо за отзыв, рад что помог!
buildSrc - это тоже вариант, но у него есть свои ограничения и недостатки в части кэширования сборки и пр. :)
Возможно, это поможет с подключением: при использовании композитных сборок (
composite builds) вместоbuildSrcсамый важный момент - это правильно прописать подключение модуля с плагинами в основной проект. В файлеsettings.gradle.ktsосновного проекта нужно указывать неinclude(":convention-plugins:base"), аincludeBuild("convention-plugins/base")- без двоеточий, как обычный путь до директории, где лежитbuild.gradle.kts-файл модуля с плагинами (довольно часто встречающаяся ошибка)Судя по логу ошибки, в модуле
:plugins:baseесть sourceSet test (папка test), для которого не задан android-плагин... Удалите и попробуйте синхронизировать проект. Если проект выложен в публичный репозиторий, было бы проще разобратьсяКак раз вчера вышло - welcome :)
Хорошая статья, было интересно почитать. Я бы еще обозначил пару важных моментов:
1. В реализации функции `Di.instance()` было бы неплохо бросать более понятную ошибку, что класс такой-то не зарегистрирован в графе. Ну и в случае миграции ключей зависимостей с простых `KClass` на составные (по типу как в Koin), может появиться еще одна ошибка о том, что возвращаемый тип не совпадает;
2. Стоит отметить, что c `Map`-ой фабрик не получится сделать проверку графа зависимостей во время компиляции и есть риск упасть в рантайме с такой реализацией DI.