Как стать автором
Обновить

Комментарии 24

Каскадный релиз snapshot'ов не знаете как сделать? Я имею ввиду, что у меня есть проект в версии SNAPSHOT. Он использует , которая тоже SNAPSHOT. Release плагин не даст сделать релиз с такой депенденсей, придется руками ее релизить. Нет ли автоматического тула, который релизнул бы все сразу?
Я такого тулза не знаю.
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.

Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
Если интересно, могу понудеть «почему».

Интересно, хотя я и сам испытывал на себе радости изменений snapshot'Ов :)
Мне кажется, что команда Мавена уже сама не рада, что они придумали снепшоты и поддержку их на уровне репозиториев.
Обычно главным минусом снепшотов в иностранных блогах называют «зависимость от нестабильной, потенциально сломанной версии».
Но в реальности, основная проблема — это синхронизация снепшота между общим репозиторием команды и локальным разработчика.

— Петя, в твоей либе бага, поправь!
— Пофиксил, комрады! В репозитории!
— Спасибо, Петя!

через час.

— Петя, в твоей либе бага, поправь!
— Пофиксил, комрады! В репозитории!
— Петя, ни чего ты не пофиксил! У нас все та же бага!
— Пофиксил, комрады :( В репозитории :(

Комрады начинают разбираться, почему фикс в библиотеке Пети не работает на их машинах, и выясняют, что Мавен просто не скачивает обновленный снепшот с общего репозитория.
Потому что Мавен обновляет снепшоты раз в сутки.
Есть workaround, силой заставить Мавен проверять обновление снепшотов при каждой сборке.

<updatePolicy>never</updatePolicy>


Но мой взгляд это уже деревянная подпорка, под стройное кирпичное здание вашего проекта. Если снепшотов будет много, то обновления заметно замедлят каждый билд. А медленный билд — это проблемы с continious integration.
В третьей версии уже хорошо заметна тенденция Maven к использованию точных номеров версий для плагинов и отказу от снепшот зависимостей. Они понимают, что и зависимость от непонятно чего, и проверка обновления каждый билд — зло.

Как тогда вести два параллельно развивающихся проекта? Для своих проектов я веду честный версионинг.
Даже если мне придется собрать два релиза в день, в каждом по одному багу. Это помогает отслеживать изменения в релизе в багтрекере и в целом держать проекты в форме. Но это, конечно, тема отдельной статьи.

Continuous integration системы как раз предназначены для того, чтобы быстро выявить проблему либо в коде самого приложения, либо в коде snapshot-зависимости (при условии, что в нем были изменения). Для того, чтобы Maven всегда обновлял snapshot-зависимости, достаточно прописать в репозитории следующее:
<code:xml>
true
always

Прошу прощения, никак не совладать с парсером. В общем, нужно создать child элемент snapshots и в нем 2 child элемента enabled (значение true) и updatePolicy (значение always).

snapshots
— enabled:true
— updatePolicy:always
/snapshots
Да, да.
Я как раз и имел ввиду:

<updatePolicy>always</updatePolicy>


Хотите, можно идти таким путем. Я просто его не выбираю.

На мой взгляд, выявлением проблемы в коде snapshot-зависимости, должна заниматься билд-конфигурация самой зависимости. А не проекта, где ее используют. Разделяй и властвуй.

Дело в том, что проблема не всегда в коде snapshot-зависимости :) Проблема может быть и в том, что ваш проект использует какой-нибудь класс или метод, который был удален или переименован. Конечно, по-хорошему, API библиотек не должен меняться, однако это не всегда так.

И пример из практики. Предположим, есть ядро системы и есть различные модули. Ядро разрабатывает одна команда, модули — другие команды. Модули зависимы от ядра (используют его библиотеки). При этом нужно поддерживать консистентное состояние — trunk модулей должен собираться с trunk'ом ядра. Сборка модулей со снэпшотом trunk'а ядра как раз и позволяет следить за этим.

Если вы используете библиотеку не вашего проекта, то, конечно, стоит десять раз подумать, прежде чем писать в слово SNAPSHOT.
Пример жизненный и понятный. Это как раз то слепое пятно, где от снепшотов не обойтись.
В своей практике я стараюсь держать ядро и модули в одном maven-проекте для обеспечения постоянной связанности. До тех пор, пока ядро не будет достаточно стабильно, чтобы перейти на раздельные проекты и систему релиз-зависимостей. Но я понимаю, что не всегда это возможно.

По поводу библиотеки не своего проекта, полностью с вами согласен.
До некоторого момента так и было (ядро и модули были одним целым). Однако, разделение проекта на составные части дало гораздо больше преимуществ, чем недостатков. Правда, я думаю это в первую очередь связано с тем, что речь идет о крупном проекте (около 1 млн строк кода).
Вместо

<updatePolicy>never</updatePolicy>

читать

<updatePolicy>always</updatePolicy>

Прошу прощения за оплошность.
Да, ситуации бывают. Но с другой стороны есть отличия SNAPSHOTов от новой версии. Все-таки автоматическое подсасываение нового кода может быть и правильным путем при активной разработке, нежели постоянный клич — «пофиксал, инкрементим версию». Серьезный nicht при работе со snapshot'ами — это смена API артефакта (удаление классов туда тоже относится естественно), вот тут как раз лучше версию инкрементить, с другой стороны как-то очень просто это правило нарушить.

Но в принципе конечно — «обезьян с гранатой» нужно опасаться.

Кстати
Есть workaround, силой заставить Мавен проверять обновление снепшотов при каждой сборке.

Достаточно собирать c ключом -U
да, точно. забыл про этот ключ. Спасибо.
По хорошему, при релизе вашего проекта и создании тега в VCS, в нем не должно быть snapshot-зависимостей. Цель тега как раз в том, чтобы зафиксировать состояние проекта. А в случае snapshot-зависимости это невозможно.
Да, именно поэтому мавен запрещает существование снепшот-зависимости при релизе.
Нет, мне не нужно релизить со SNAPSHOTами. Я хочу просто как раз зафиксировать версию SNAPSHOTовых зависимостей, чтобы в своем артефакте ссылатся на ту версию зависимости, которая использовалась в разработке.
в целом я согласен, но и с SNAPSHOT зависимостями можно зафиксировать состояние проекта — см lock-snapshots в maven-version-plugin
это вопрос в духе «как мне выстрелить себе в ногу?»
Каскадный релиз snapshot'ов разных библиотек?! Либо это не разные библиотеки, а модули одного проекта (и тогда maven-release-plugin зарелизит все модули «каскадно»), либо Вы недопонимаете, как важно беречь независимость разных библиотек, даже если их реализацией занимается одна команда.

В текущем проекте я организовал следующий подход:
Допустим имеется проект A-1.0-RC1-snapshot, который использует B-alpha-2-snapshot и С-alpha-7-snapshot.

Прежде чем заморозить проект A, я замораживаю проект B:
B-alpha-2-snapshot => B-alpha-2 => B-alpha-3-snapshot

Далее прошу owner-a проекта C (это другая команда) также выпустить промежуточный релиз:
С-alpha-7-snapshot => С-alpha-7 = С-alpha-8-snapshot

После того как все зависимости стабилизированы и заморожены можно замораживать проект A:
A-1.0-RC1-snapshot => A-1.0-RC1 => A-1.0-RC2-snapshot

И еще раз: плагина который делал бы каскадный релиз по нескольким проектам не существует, и я очень надеюсь что его никогда не появится.

попытайтесь использовать опцию allowTimestampedSnapshots
Я такого тулза не знаю.
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.

Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
Огромное спасибо! Попытаюсь навести порядок в своей системе.
Рад помочь!
все таки Maven это ад и зло… JVZлу надо поотрывать руки и засунуть… чего-то я замечтался… Ребят, я вам очень горячо рекомендую посмотреть на Gradle. Тут уже про него писали когда-то, но если есть конкретные вопросы буду рад ответить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории