AN
Вот это легко решается отдельными плагинами
Решается - да, но это не то, что хочется. Хочется имет плагин, который обслуживает задачу.
Size: a a a
2019 October 17
AN
Я не говорю, что градл плохой. Я говорю, что его структура нашла свой потолок. И на Kts это особенно заметно
VP
Я не говорю, что градл плохой. Я говорю, что его структура нашла свой потолок. И на Kts это особенно заметно
Вот kts больше всего страдает от такой динамической структуры, когда будет плагин применён или нет - зависит от каких-то действий в билд-скрипте.
Лучше так не делать.
Лучше так не делать.
BV
В грейдле сделана система биндингов, изменения отражаются, те если ты поменял что-то в конфиге это отразится в тасках к примеру или можно что-то делать когда конфиг уже применили, там много способов
VP
Вот это легко решается отдельными плагинами
А, кстати, есть ещё решение - не подключать другие плагины по условию, а реагировать на их подключение.
Кода будет столько же, но набор плагинов понятен сразу и известен до исполнения билд-скрипта.
Кода будет столько же, но набор плагинов понятен сразу и известен до исполнения билд-скрипта.
AN
Вот kts больше всего страдает от такой динамической структуры, когда будет плагин применён или нет - зависит от каких-то действий в билд-скрипте.
Лучше так не делать.
Лучше так не делать.
А я не говорю про динамическую структуру. Я напротив говорю, что конфигурирование плагинов должно быть вынесено из билдскрипта совсем.
VP
А я не говорю про динамическую структуру. Я напротив говорю, что конфигурирование плагинов должно быть вынесено из билдскрипта совсем.
Оно и так фактически не там
AN
А, кстати, есть ещё решение - не подключать другие плагины по условию, а реагировать на их подключение.
Кода будет столько же, но набор плагинов понятен сразу и известен до исполнения билд-скрипта.
Кода будет столько же, но набор плагинов понятен сразу и известен до исполнения билд-скрипта.
Ну я так и делаю
BV
А я не говорю про динамическую структуру. Я напротив говорю, что конфигурирование плагинов должно быть вынесено из билдскрипта совсем.
Что за билдскрипт такой где конфигурируются плагины?
VP
А вы в том примере пытаетесь сделать динамически
AN
Оно и так фактически не там
Фактически там. У вас экстеншены, которые реально конфигурируют плагины, там же, где и применение плагинов
VP
Ну я так и делаю
Нет, вы сами делаете apply по вызову withSerialization например.
AN
А вы в том примере пытаетесь сделать динамически
неа, там просто эктеншен подрубает кусок плагина.
BV
Хотя я соглашусь, что флоу далёк от идеала
AN
Нет, вы сами делаете apply по вызову withSerialization например.
там унутре я подключаю фичи в зависимости от того, какие плагины подключены.
VP
там унутре я подключаю фичи в зависимости от того, какие плагины подключены.
Зачем тогда эти withDokka и withSerialization?
AN
Зачем тогда эти withDokka и withSerialization?
Потому что я не хочу подключать плагин доки и для каждого проекта дублировать конфигурацию. Я хочу, чтобы в моем плагине были готовые настройки под мои задачи, которые я подключаю одной строкой.
VP
Потому что я не хочу подключать плагин доки и для каждого проекта дублировать конфигурацию. Я хочу, чтобы в моем плагине были готовые настройки под мои задачи, которые я подключаю одной строкой.
Так вы один фиг дублируете эти вызовы, в чём разница, рекурсивное применение к подпроектам?
AN
В принципе, правильнее наверное было бы сделать это топ левел функцией типа
Project.withDokka(), но эта штука будет плохо дружить с подгрузкой ktsAN
Так вы один фиг дублируете эти вызовы, в чём разница, рекурсивное применение к подпроектам?
Настройки одинаковые. Пока их там нет, но будут.