У меня есть проект А, который зависит от проекта Б; оба являются внутренними проектами в активной разработке.
Скажем, последняя версия проекта A - 1.1.2, которая зависит от проекта B 1.1.1.
Сейчас мы разрабатываем проект A 1.2.0, который также зависит от проекта B 1.2.0.
<dependency org="my.org" name="projectB" rev="1.2.0" transitive="true" conf="..." changing="true"/>
Новые интеграционные сборки для проекта B 1.2.0 помещаются сервером CI в общий локальный репозиторий, поэтому благодаря «изменению» каждый получает последние интеграционные сборки сразу после их публикации.
Скажите, что Боб разрабатывает новую функцию в Проекте А, которая требует некоторых модификаций для Проекта Б; он публикует новый shapshot Project B 1.2.0 в своем локальном частном репозитории, и его собирают в сборке, потому что он более поздний, чем в общем репозитории. Пока все ок.
Но если Алиса что-то фиксирует в Проекте B, сервер CI выдвигает новую версию 1.2.0 для общего репо, которая является более новой, чем та, которую Боб имеет локально; теперь Боб получает общую версию, которая отменяет его локальные изменения.
Конечно, я мог бы использовать разные имена (используя файлы свойств умным образом, чтобы имя не заканчивалось на ivy.xml), что-то вроде 1.2.0_snapshot для Боба, если Бобу нужна локальная версия, а затем переключитесь обратно на 1.2.0, когда общая версия будет в порядке.
Но разве нет способа принудительно использовать артефакт с состоянием «моментальный снимок» (который всегда будет статусом локальных сборок) по сравнению с теми, у которых есть «интеграция» (те, что произведены сервером CI, всегда будут иметь этот статус) или выше
Я попробовал "latest.snapshot", но он принимает версию интеграции, если она более поздняя.
Как лучше всего справиться с этим паттерном?