как сделать стабильный релиз при использовании Maven и SVN

Question

у нас есть около 100 maven артефактов в нашем Java-проекте. Эти артефакты относятся к 5 различным продуктам. очевидно, что некоторые из них разделены между продуктами.

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

скажем: модуль A зависит от модуля B, который является версией моментального снимка. Я помечаю модуль A в SVN для выпуска или вехи или ... позже, если кто-то поменяет модуль B, это может повлиять на помеченную версию. в следующий раз, если я попытаюсь собрать версию тега, у меня будет сломанная сборка.

есть ли способ решить эту проблему?

Я не хочу использовать профиль, чтобы остановить обновление снимка.

Спасибо всем.

Answer 1

Я не отмечаю версию, если она зависит от того, какая версия является снимком.

Answer 2

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

Вы определили проблему, и ответ очевиден: вы должны использовать фиксированные версии только при выпуске. Есть два плагина, которые могут помочь упростить весь процесс:

• Плагин Maven Release , полностью поддерживающий автоматизацию "правильного" рабочего процесса (см. Подготовка выпуска ).
• Плагин Versions Maven имеет несколько полезных целей для обновления набора POM, если вы не можете или не используете плагин релиза. В частности, отметьте versions:update-parent и versions:update-child-modules.

Но суть в том, что исправляйте свои версии при выпуске (и пометки) для последующей воспроизводимости.

Answer 3

Если вы используете maven-release-plugin для освобождения ваших компонентов, он выполнит проверку зависимостей и прекратит сборку при обнаружении зависимости моментального снимка.

Answer 4

Несмотря на то, что я согласен с Борисом и Паскалем, есть два пути:

1. Вы создаете каждую сборку только один раз.Поэтому у вас есть код для исследования ошибки (нужно надеяться, что ошибка не входит ни в одну из ваших зависимостей).Главное преимущество заключается в том, что у вас есть ровно один двоичный файл, который вы можете перемещать по всем средам вплоть до производства.Существует только одно требование.Приложение должно быть независимым от окружения.

2. пометить весь scm, включая все снимки.Когда вы создаете код, чем, вы должны проверить свой проект и все зависимости.И строить их в правильном порядке, чтобы у вас были точно такие же результаты.Это утомительно со многими зависимостями, и если задействовано более одного SCM.

Конечно, вы можете попытаться смешать два подхода.Так что вы помечаете свой собственный проект и, возможно, некоторые зависимости.Все остальные зависимости хранят необходимый артефакт (включая pom для установки в локальный репозиторий), так что вы можете перезапустить сборку, когда захотите.

Это должен быть временный обходной путь до тех пор, пока выудалось использовать только освобожденные зависимости.