В отличие от других, я думаю, что есть много причин, почему вы всегда можете хотеть последнюю версию. Особенно, если вы делаете непрерывное развертывание (у нас иногда бывает около 5 выпусков в день) и вы не хотите делать многомодульный проект.
Что я делаю, так это заставляю Хадсона / Дженкинса делать следующее для каждой сборки:
mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true
То есть я использую плагин версий и плагин scm для обновления зависимостей, а затем возвращаю его в систему контроля версий. Да, я позволил моему CI выполнять проверки SCM (что вы должны сделать в любом случае для плагина релиза maven).
Вы захотите настроить плагин версий для обновления только того, что вы хотите:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<includesList>com.snaphop</includesList>
<generateBackupPoms>false</generateBackupPoms>
<allowSnapshots>true</allowSnapshots>
</configuration>
</plugin>
Я использую плагин релиза, чтобы сделать релиз, который заботится о -SNAPSHOT и проверяет, существует ли релизная версия -SNAPSHOT (что важно).
Если вы сделаете то, что я делаю, вы получите самую последнюю версию для всех сборок снимков и последнюю версию выпуска для сборок выпуска. Ваши сборки также будут воспроизводимы.
Обновить
Я заметил некоторые комментарии, спрашивающие некоторые особенности этого рабочего процесса. Я скажу, что мы больше не используем этот метод, и основная причина, по которой плагин maven version является глючной и вообще имеет недостатки.
Он имеет недостатки, потому что для запуска плагина версий для настройки версий все существующие версии должны существовать для правильной работы pom. То есть плагин версий не может обновиться до последней версии чего-либо, если он не может найти версию, на которую ссылается pom. Это на самом деле довольно раздражает, так как мы часто очищаем старые версии по соображениям дискового пространства.
На самом деле вам нужен отдельный инструмент от maven для настройки версий (чтобы вы не зависели от правильности работы pom-файла). Я написал такой инструмент на простом языке Bash. Сценарий обновит версии, такие как плагин версии, и вернет pom обратно в систему контроля версий. Он также работает примерно в 100 раз быстрее, чем плагин версий mvn. К сожалению, это не написано для публичного использования, но если бы люди заинтересовались, я мог бы сделать это и поместить его в gist или github.
Возвращаясь к рабочему процессу, когда некоторые комментарии спрашивали о том, что мы делаем:
- У нас есть около 20 проектов в собственных репозиториях со своими рабочими местами в Jenkins
- Когда мы выпускаем плагин Maven Release используется. Рабочий процесс описан в документации к плагину. Плагин Maven Release вроде отстой (и я добрый), но он работает. Однажды мы планируем заменить этот метод на что-то более оптимальное.
- Когда один из проектов будет выпущен, jenkins затем запустит специальную работу, и мы назовем задачу update all version (то, как jenkins узнает, что релиз - сложная вещь, отчасти потому, что плагин релиза maven jenkins тоже довольно дурацкий).
- Работа обновления всех версий знает обо всех 20 проектах. На самом деле это pom-агрегатор, чтобы быть конкретным со всеми проектами в разделе модулей в порядке зависимости. Дженкинс запускает нашу волшебную команду groovy / bash foo, которая будет вытягивать все проекты, обновлять версии до последних и затем регистрировать poms (снова это делается в порядке зависимости на основе раздела модулей).
- Для каждого проекта, если pom изменился (из-за изменения версии в некоторой зависимости), он регистрируется, и затем мы немедленно отправляем эхо-запрос jenkins, чтобы запустить соответствующее задание для этого проекта (чтобы сохранить порядок зависимостей сборки, в противном случае вы попали в зависимость планировщика опроса SCM).
На данный момент я считаю, что было бы хорошо, если бы релиз и автоматическая версия были отдельным инструментом от вашей общей сборки.
Теперь вы можете подумать, что maven вроде отстой из-за проблем, перечисленных выше, но на самом деле это было бы довольно сложно с инструментом сборки, который не имеет декларативного легко разбираемого расширяемого синтаксиса (иначе XML).
Фактически мы добавляем пользовательские атрибуты XML через пространства имен, чтобы помочь подсказкам сценариев bash / groovy (например, не обновлять эту версию).