развертывание файлов Maven JAR и зависимостей SNAPSHOT - PullRequest
1 голос
/ 01 сентября 2010

В настоящее время мы используем модификатор SNAPSHOT при разработке, чтобы зависимости проекта были связаны с самой последней сборкой его зависимостей. Поэтому, когда мы строим проект, мы получаем все банки с различными временными СНАПШОТАМИ. Независимо от изменения кода.

Это оказывается проблемой, когда конечный пользователь хочет загрузить новую версию. Например, есть большой jar-файл, который редко обновляется. Мы бы хотели, чтобы этот конкретный jar-файл назывался версией 1.4, как предполагается, 1.4-SNAPSHOT, когда мы выпускаем его для клиента, то есть они загружают новую версию только тогда, когда мы вносим изменения в номер версии, как предполагалось, когда мы в последний раз построено с изменениями или без них.

Каков наилучший способ достичь этого? Я что-то упустил?

Пожалуйста и спасибо.

Ответы [ 2 ]

1 голос
/ 01 сентября 2010

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

Прежде всего, релизы должны действительно использовать фиксированные версии. Так что, если вы разрабатываете версию 1.4-SNAPSHOT, предполагается, что версия выпуска будет 1.4 (и вы пометите ее как таковую в вашей VCS). А затем вы поднимаете новую версию разработки до 1.5-SNAPSHOT в ветке dev.

Например, есть большой файл jar, который редко обновляется. Мы бы хотели, чтобы этот конкретный jar-файл назывался версией 1.4 (...)

Но даже если вы будете следовать вышеупомянутому «стандартному» процессу, ничто не заставит вас выпустить все версии после выпуска, и вы можете просто придерживаться определенной фиксированной версии определенного артефакта. Это устранит проблему.

0 голосов
/ 01 сентября 2010

По моему мнению, путь к пользователю является своего рода доставкой и должен обрабатываться с использованием процесса выпуска maven (выпуск mvn), который автоматически увеличивает номера версий. Чем у вас есть точное отношение к вашему контролю версий и что у пользователя есть. SNAPSHOT следует использовать только в разработке.

...