Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Каскадный релиз snapshot'ов не знаете как сделать? Я имею ввиду, что у меня есть проект в версии SNAPSHOT. Он использует , которая тоже SNAPSHOT. Release плагин не даст сделать релиз с такой депенденсей, придется руками ее релизить. Нет ли автоматического тула, который релизнул бы все сразу?
Я такого тулза не знаю.
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.
Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.
Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
Если интересно, могу понудеть «почему».
Интересно, хотя я и сам испытывал на себе радости изменений snapshot'Ов :)
Мне кажется, что команда Мавена уже сама не рада, что они придумали снепшоты и поддержку их на уровне репозиториев.
Обычно главным минусом снепшотов в иностранных блогах называют «зависимость от нестабильной, потенциально сломанной версии».
Но в реальности, основная проблема — это синхронизация снепшота между общим репозиторием команды и локальным разработчика.
Комрады начинают разбираться, почему фикс в библиотеке Пети не работает на их машинах, и выясняют, что Мавен просто не скачивает обновленный снепшот с общего репозитория.
Потому что Мавен обновляет снепшоты раз в сутки.
Есть workaround, силой заставить Мавен проверять обновление снепшотов при каждой сборке.
Но мой взгляд это уже деревянная подпорка, под стройное кирпичное здание вашего проекта. Если снепшотов будет много, то обновления заметно замедлят каждый билд. А медленный билд — это проблемы с continious integration.
В третьей версии уже хорошо заметна тенденция Maven к использованию точных номеров версий для плагинов и отказу от снепшот зависимостей. Они понимают, что и зависимость от непонятно чего, и проверка обновления каждый билд — зло.
Как тогда вести два параллельно развивающихся проекта? Для своих проектов я веду честный версионинг.
Даже если мне придется собрать два релиза в день, в каждом по одному багу. Это помогает отслеживать изменения в релизе в багтрекере и в целом держать проекты в форме. Но это, конечно, тема отдельной статьи.
Обычно главным минусом снепшотов в иностранных блогах называют «зависимость от нестабильной, потенциально сломанной версии».
Но в реальности, основная проблема — это синхронизация снепшота между общим репозиторием команды и локальным разработчика.
— Петя, в твоей либе бага, поправь!
— Пофиксил, комрады! В репозитории!
— Спасибо, Петя!
через час.
— Петя, в твоей либе бага, поправь!
— Пофиксил, комрады! В репозитории!
— Петя, ни чего ты не пофиксил! У нас все та же бага!
— Пофиксил, комрады :( В репозитории :(
Комрады начинают разбираться, почему фикс в библиотеке Пети не работает на их машинах, и выясняют, что Мавен просто не скачивает обновленный снепшот с общего репозитория.
Потому что Мавен обновляет снепшоты раз в сутки.
Есть workaround, силой заставить Мавен проверять обновление снепшотов при каждой сборке.
<updatePolicy>never</updatePolicy>
Но мой взгляд это уже деревянная подпорка, под стройное кирпичное здание вашего проекта. Если снепшотов будет много, то обновления заметно замедлят каждый билд. А медленный билд — это проблемы с continious integration.
В третьей версии уже хорошо заметна тенденция Maven к использованию точных номеров версий для плагинов и отказу от снепшот зависимостей. Они понимают, что и зависимость от непонятно чего, и проверка обновления каждый билд — зло.
Как тогда вести два параллельно развивающихся проекта? Для своих проектов я веду честный версионинг.
Даже если мне придется собрать два релиза в день, в каждом по одному багу. Это помогает отслеживать изменения в релизе в багтрекере и в целом держать проекты в форме. Но это, конечно, тема отдельной статьи.
Continuous integration системы как раз предназначены для того, чтобы быстро выявить проблему либо в коде самого приложения, либо в коде snapshot-зависимости (при условии, что в нем были изменения). Для того, чтобы Maven всегда обновлял snapshot-зависимости, достаточно прописать в репозитории следующее:
<code:xml>
true
always
<code:xml>
true
always
Прошу прощения, никак не совладать с парсером. В общем, нужно создать child элемент snapshots и в нем 2 child элемента enabled (значение true) и updatePolicy (значение always).
snapshots
— enabled:true
— updatePolicy:always
/snapshots
snapshots
— enabled:true
— updatePolicy:always
/snapshots
Да, да.
Я как раз и имел ввиду:
Хотите, можно идти таким путем. Я просто его не выбираю.
На мой взгляд, выявлением проблемы в коде snapshot-зависимости, должна заниматься билд-конфигурация самой зависимости. А не проекта, где ее используют. Разделяй и властвуй.
Я как раз и имел ввиду:
<updatePolicy>always</updatePolicy>
Хотите, можно идти таким путем. Я просто его не выбираю.
На мой взгляд, выявлением проблемы в коде snapshot-зависимости, должна заниматься билд-конфигурация самой зависимости. А не проекта, где ее используют. Разделяй и властвуй.
Дело в том, что проблема не всегда в коде snapshot-зависимости :) Проблема может быть и в том, что ваш проект использует какой-нибудь класс или метод, который был удален или переименован. Конечно, по-хорошему, API библиотек не должен меняться, однако это не всегда так.
И пример из практики. Предположим, есть ядро системы и есть различные модули. Ядро разрабатывает одна команда, модули — другие команды. Модули зависимы от ядра (используют его библиотеки). При этом нужно поддерживать консистентное состояние — trunk модулей должен собираться с trunk'ом ядра. Сборка модулей со снэпшотом trunk'а ядра как раз и позволяет следить за этим.
Если вы используете библиотеку не вашего проекта, то, конечно, стоит десять раз подумать, прежде чем писать в слово SNAPSHOT.
И пример из практики. Предположим, есть ядро системы и есть различные модули. Ядро разрабатывает одна команда, модули — другие команды. Модули зависимы от ядра (используют его библиотеки). При этом нужно поддерживать консистентное состояние — trunk модулей должен собираться с trunk'ом ядра. Сборка модулей со снэпшотом trunk'а ядра как раз и позволяет следить за этим.
Если вы используете библиотеку не вашего проекта, то, конечно, стоит десять раз подумать, прежде чем писать в слово SNAPSHOT.
Пример жизненный и понятный. Это как раз то слепое пятно, где от снепшотов не обойтись.
В своей практике я стараюсь держать ядро и модули в одном maven-проекте для обеспечения постоянной связанности. До тех пор, пока ядро не будет достаточно стабильно, чтобы перейти на раздельные проекты и систему релиз-зависимостей. Но я понимаю, что не всегда это возможно.
По поводу библиотеки не своего проекта, полностью с вами согласен.
В своей практике я стараюсь держать ядро и модули в одном maven-проекте для обеспечения постоянной связанности. До тех пор, пока ядро не будет достаточно стабильно, чтобы перейти на раздельные проекты и систему релиз-зависимостей. Но я понимаю, что не всегда это возможно.
По поводу библиотеки не своего проекта, полностью с вами согласен.
Вместо
читать
Прошу прощения за оплошность.
<updatePolicy>never</updatePolicy>
читать
<updatePolicy>always</updatePolicy>
Прошу прощения за оплошность.
Да, ситуации бывают. Но с другой стороны есть отличия SNAPSHOTов от новой версии. Все-таки автоматическое подсасываение нового кода может быть и правильным путем при активной разработке, нежели постоянный клич — «пофиксал, инкрементим версию». Серьезный nicht при работе со snapshot'ами — это смена API артефакта (удаление классов туда тоже относится естественно), вот тут как раз лучше версию инкрементить, с другой стороны как-то очень просто это правило нарушить.
Но в принципе конечно — «обезьян с гранатой» нужно опасаться.
Кстати
Достаточно собирать c ключом -U
Но в принципе конечно — «обезьян с гранатой» нужно опасаться.
Кстати
Есть 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
И еще раз: плагина который делал бы каскадный релиз по нескольким проектам не существует, и я очень надеюсь что его никогда не появится.
В текущем проекте я организовал следующий подход:
Допустим имеется проект 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 зависимостей в проектах. Если интересно, могу понудеть «почему».
Но, насколько я понимаю структуру Мавена, если такая тулза и есть, то она написана руками энтузиастов, которым нужен такой же юзкейс как вам. Ничего официального.
Сам я против SNAPSHOT зависимостей в проектах. Если интересно, могу понудеть «почему».
Огромное спасибо! Попытаюсь навести порядок в своей системе.
все таки Maven это ад и зло… JVZлу надо поотрывать руки и засунуть… чего-то я замечтался… Ребят, я вам очень горячо рекомендую посмотреть на Gradle. Тут уже про него писали когда-то, но если есть конкретные вопросы буду рад ответить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем релизы с помощью Maven в Java