А вот вы никогда не задумывались, почему мавен (якобы) медленнее? Может от того что многопоточность в нем по умолчанию выключена? Кмк, я видел разоблачающую статью показывающую, что разница далеко не на порядки.
Инструмент, он невиноват, когда его неправильно используют. 100% тормозов в мавене, да и грейдле, были вызваны кривыми руками. И там и там можно такого натворить, что е-ге-гей!
Gradle развивается на тех-же принципах и подходах что и maven. В него пишут и тянут неимоверное количество плагинов, как результат, сборка занимает не пойми сколько, отчего упала непонятно, куда бежать — неясно (конечно, это со стороны моего опыта).
Подход, когда все разделено и физически невозможно смешать, мне гораздо ближе: релиз разбивается на конечное число атомарных шагов, простых и понятных. Но, пока мы не там.
Вы, либо выбрали наркотики микро-сервисы и собираете проекты, потому что вам нужно, и тогда проблема решается сама собой (на локальной машине, можно собрать локально snapshot версию и подключить, временно, ее). Либо, вы столкнулись с одним из недостатков и такой способ сборки вам не подходит.
Как еще один вариант: собирать snapshot и ставить версию = хешу, в случае когда тег не определен.
В таком варианте есть свои плюсы и минусы: к плюсом можно отнести однозначное понимание что попало в сборку, разночтений быть не может; к минусам, неочевидно куда мы движемся меняя одну страшную строчку на другую, семантическая версионность говорит нам идем ли мы вперед (версия стала больше) или назад (меньше).
Что верно то верно. :-D Подход maven к организации проекта привел к «ожирению» системы, переход на gradle позволяет писать меньше и косячить еще быстрее! Кмк будущее за разделением на небольшие утилиты, каждая из которых делает одну вещь и делает ее хорошо. А вместе организуется CI/CD. Подвижки есть в этом направлении, но замахнуться на священный maven, пока, не решился никто.
Если-б, вы когда нибудь пытались запустить сборку iOS приложения в контейнере?
Экосистема настолько закрыта и отстала, что это требует неимоверных танцев с бубном, по крайне мере так было, когда я смотрел в последний раз. Правда, может все изменилось?
Позвольте мне не согласится, у нас есть свой продукт, есть десятки тысяч пользователей, 4,4 <1%… Конечно же, выбирая технологии, вы должны, в первую очередь, опираться на статистику вашего продукта.
Но жизнь не стоит на месте и эта статься вполне полезна и читать ее нужно даже вам, если вы планируете интегрировать линки в свой продукт когда нибудь. Если же вы не планируете развивать продукт, то, в общем-то, можно вообще все статьи сразу закрывать.
Мда, где то я вдел этого автора ;-)
Тем не менее у этого подхода есть и свои минусы. Товарищъ выше говорит о вполне интересной альтернативе, когда проект собирает только джарники, а дальше они сдаются следующему шагу, который пакует докер или еще чего непотребного делает.
Такой подход должен лучше ложится на современные представления о CI/CD.
Инструмент, он невиноват, когда его неправильно используют. 100% тормозов в мавене, да и грейдле, были вызваны кривыми руками. И там и там можно такого натворить, что е-ге-гей!
Подход, когда все разделено и физически невозможно смешать, мне гораздо ближе: релиз разбивается на конечное число атомарных шагов, простых и понятных. Но, пока мы не там.
наркотикимикро-сервисы и собираете проекты, потому что вам нужно, и тогда проблема решается сама собой (на локальной машине, можно собрать локально snapshot версию и подключить, временно, ее). Либо, вы столкнулись с одним из недостатков и такой способ сборки вам не подходит.Как еще один вариант: собирать snapshot и ставить версию = хешу, в случае когда тег не определен.
В таком варианте есть свои плюсы и минусы: к плюсом можно отнести однозначное понимание что попало в сборку, разночтений быть не может; к минусам, неочевидно куда мы движемся меняя одну страшную строчку на другую, семантическая версионность говорит нам идем ли мы вперед (версия стала больше) или назад (меньше).
Экосистема настолько закрыта и отстала, что это требует неимоверных танцев с бубном, по крайне мере так было, когда я смотрел в последний раз. Правда, может все изменилось?
Запуск на локальной машине решает мало проблем. А вот как все это вертеть в контейнере на абстрактном CI/CD?
массондевопсСкажите пожалуйста, а остальные 30%, что применяют?
Но жизнь не стоит на месте и эта статься вполне полезна и читать ее нужно даже вам, если вы планируете интегрировать линки в свой продукт когда нибудь. Если же вы не планируете развивать продукт, то, в общем-то, можно вообще все статьи сразу закрывать.
Тем не менее у этого подхода есть и свои минусы. Товарищъ выше говорит о вполне интересной альтернативе, когда проект собирает только джарники, а дальше они сдаются следующему шагу, который пакует докер или еще чего непотребного делает.
Такой подход должен лучше ложится на современные представления о CI/CD.
Ну да ладно, покумекаю на досуге.