Комментарии 8
А чем подход Гугла из nio не подошёл? Наделать kt файлов в buil-logic модуле и подключать их как плагины. Вроде норм решение же.
Но надо переезжать с groove, что в общем-то проблема только в первый раз.
А чем подход Гугла из nio не подошёл? Наделать kt файлов в buil-logic модуле и подключать их как плагины. Вроде норм решение же.
На момент написания статьи этот подход мне не попадался. Спасибо, что подсказали, буду изучать.
Я немного посмотрел и, как я понимаю, с Version Catalogs этот подход пока работает хуже, чем в обычных gradle-файлах, а я эту фичу использую, так что пока этот подход мне подходит меньше, но может ещё разберусь как сделать это сопоставимо удобно.
В любом случае спасибо за наводку.
Но надо переезжать с groove, что в общем-то проблема только в первый раз.
Это как раз и главная проблема( Меня обычно кидает на legacy, поэтому я чаще работаю именно с Groovy, а потому на него и ориентируюсь в первую очередь.
@DropDrage Там свой version Catalog будет, чисто kt-ный (вроде бы этот toml файл groovy не понимает)
Там есть автодополнения в kt файлах, в целом мне понравилось больше чем чем groovy (но я сами скрипты не писал никогда, делал переезд с groovy на kt)
Плюс всю вашу логику можно будет аккуратно вынести в плагины, выглядеть будет симпатичнее.
Но первый раз переезд может занять время, там есть неочевидные (по крайней мере для меня) моменты
Мне хотелось найти что-то легко реализуемое безо всяких там плагинов, buildSrc и отдельных модулей с зависимостями и настройками.
Вы ведь сами изобрели свои плагины, почему не использовать решение для плагинов, которое есть из коробки?
И работает ли ваша система с Configuration Cache?
Вы ведь сами изобрели свои плагины, почему не использовать решение для плагинов, которое есть из коробки?
Плагины я не хотел в принципе использовать, поскольку читал, что они замедляют сборку, но сейчас всё же попробовал и, честно говоря, это не очень-то и удобно, ибо нет автодополнения при написании их названия, в отличие от описанной мной реализации. Также погоняв синхронизацию Gradle на тестовом проекте, я заметил стабильное её замедление на 300мс при длительности 2-3 секунды, которое скорее всего увеличивается на больших проектах, а сама сборка замедлилась минимум на 2 секунды при длительности 20 секунд из-за сборки модуля с плагинами.
В дополнение к этому, я хотел придумать максимально универсальную реализацию, чтобы она могла быть использована под любые нужды, поэтому описанная мной реализация позволяет передавать ещё и аргументы, что, как я понимаю, через плагины не сделать. Нужны ли аргументы? В большинстве случаев нет, но тем не менее может кому-то и понадобится.
И работает ли ваша система с Configuration Cache?
Да
Метрики сборки с разницей в 300мс репрезентативными не являются, это статистическая погрешность. Сборка модуля с плагинами происходит один раз, потом кэшируется, да и ваша система какой-то оверхед даст, какая разница, где лежит код, хоть в плагинах, хоть в косогорах.
Convention плагины это и есть максимально универсальная реализация. И конфигурацию они поддерживают https://docs.gradle.org/current/userguide/custom_plugins.html#sec:getting_input_from_the_build
В общем, как упражнение для разработчика чтобы разобраться в Gradle у вас получился хороший пример, но для применения в проде пока не видно ни одного преимущества по сравнению с convention плагинами :)
В современных Android-приложениях для выноса общей конфигурации давно можно использовать стандартную фичу Gradle, которая называется convention plugins.
Для примера использования можно посмотреть на проект Google Now in Android или же на проект команды Avito - avito-android.
Лучше потратить пару вечеров и разобраться, чем создавать своё решение с нуля.
Убираем дублирование конфигурации Gradle и при чём здесь косы и горы