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