Пример жизненный и понятный. Это как раз то слепое пятно, где от снепшотов не обойтись.
В своей практике я стараюсь держать ядро и модули в одном maven-проекте для обеспечения постоянной связанности. До тех пор, пока ядро не будет достаточно стабильно, чтобы перейти на раздельные проекты и систему релиз-зависимостей. Но я понимаю, что не всегда это возможно.
По поводу библиотеки не своего проекта, полностью с вами согласен.
Хотите, можно идти таким путем. Я просто его не выбираю.
На мой взгляд, выявлением проблемы в коде snapshot-зависимости, должна заниматься билд-конфигурация самой зависимости. А не проекта, где ее используют. Разделяй и властвуй.
Мне кажется, что команда Мавена уже сама не рада, что они придумали снепшоты и поддержку их на уровне репозиториев.
Обычно главным минусом снепшотов в иностранных блогах называют «зависимость от нестабильной, потенциально сломанной версии».
Но в реальности, основная проблема — это синхронизация снепшота между общим репозиторием команды и локальным разработчика.
— Петя, в твоей либе бага, поправь!
— Пофиксил, комрады! В репозитории!
— Спасибо, Петя!
через час.
— Петя, в твоей либе бага, поправь!
— Пофиксил, комрады! В репозитории!
— Петя, ни чего ты не пофиксил! У нас все та же бага!
— Пофиксил, комрады :( В репозитории :(
Комрады начинают разбираться, почему фикс в библиотеке Пети не работает на их машинах, и выясняют, что Мавен просто не скачивает обновленный снепшот с общего репозитория.
Потому что Мавен обновляет снепшоты раз в сутки.
Есть workaround, силой заставить Мавен проверять обновление снепшотов при каждой сборке.
<updatePolicy>never</updatePolicy>
Но мой взгляд это уже деревянная подпорка, под стройное кирпичное здание вашего проекта. Если снепшотов будет много, то обновления заметно замедлят каждый билд. А медленный билд — это проблемы с continious integration.
В третьей версии уже хорошо заметна тенденция Maven к использованию точных номеров версий для плагинов и отказу от снепшот зависимостей. Они понимают, что и зависимость от непонятно чего, и проверка обновления каждый билд — зло.
Как тогда вести два параллельно развивающихся проекта? Для своих проектов я веду честный версионинг.
Даже если мне придется собрать два релиза в день, в каждом по одному багу. Это помогает отслеживать изменения в релизе в багтрекере и в целом держать проекты в форме. Но это, конечно, тема отдельной статьи.
Я такого тулза не знаю.
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.
Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
Я такого тулза не знаю.
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.
Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
В своей практике я стараюсь держать ядро и модули в одном maven-проекте для обеспечения постоянной связанности. До тех пор, пока ядро не будет достаточно стабильно, чтобы перейти на раздельные проекты и систему релиз-зависимостей. Но я понимаю, что не всегда это возможно.
По поводу библиотеки не своего проекта, полностью с вами согласен.
читать
Прошу прощения за оплошность.
Я как раз и имел ввиду:
Хотите, можно идти таким путем. Я просто его не выбираю.
На мой взгляд, выявлением проблемы в коде snapshot-зависимости, должна заниматься билд-конфигурация самой зависимости. А не проекта, где ее используют. Разделяй и властвуй.
Обычно главным минусом снепшотов в иностранных блогах называют «зависимость от нестабильной, потенциально сломанной версии».
Но в реальности, основная проблема — это синхронизация снепшота между общим репозиторием команды и локальным разработчика.
Комрады начинают разбираться, почему фикс в библиотеке Пети не работает на их машинах, и выясняют, что Мавен просто не скачивает обновленный снепшот с общего репозитория.
Потому что Мавен обновляет снепшоты раз в сутки.
Есть workaround, силой заставить Мавен проверять обновление снепшотов при каждой сборке.
Но мой взгляд это уже деревянная подпорка, под стройное кирпичное здание вашего проекта. Если снепшотов будет много, то обновления заметно замедлят каждый билд. А медленный билд — это проблемы с continious integration.
В третьей версии уже хорошо заметна тенденция Maven к использованию точных номеров версий для плагинов и отказу от снепшот зависимостей. Они понимают, что и зависимость от непонятно чего, и проверка обновления каждый билд — зло.
Как тогда вести два параллельно развивающихся проекта? Для своих проектов я веду честный версионинг.
Даже если мне придется собрать два релиза в день, в каждом по одному багу. Это помогает отслеживать изменения в релизе в багтрекере и в целом держать проекты в форме. Но это, конечно, тема отдельной статьи.
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.
Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.
Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».