2013-03-21 6 views
4

Сегодня, выполняя выпуск нашего проекта, выпуск: выполнить команду не удалось между ними, так как наша связь имела прерывистые проблемы. Команда release может загружать только один файл pom в nexus.maven release выполнить не удалось

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

Есть ли способ передать аргумент, чтобы release: выполнить следует, если файл уже существует и игнорировать это, но продолжить с загрузкой остальных.

Я искал варианты такого типа, но ничего не нашел.

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

Я использую Maven 2.2.1

ответ

8

Вот как я обработал это в прошлом. Команда release:perform выполняет проверку тега у вашего поставщика SCM (например, SVN). Это делается в target/checkout каталоге этого проекта - то, что это не должна быть точной копией отпущенного тега, поэтому он будет иметь правильный номер версия в П файлов и т.д.

Если вы переезжаете в этот каталог (target/checkout в каталоге, в котором вы начали выпуск), вы можете просто сделать mvn deploy там, и он должен скомпилировать и упаковать эту версию, а затем загрузить ее в экземпляр Nexus.

Если у вас нет каталога target/checkout, вы можете проверить тег, созданный в рамках release:prepare фазы из системы SCM в свежий каталог и запустить mvn deploy там.

Поскольку тег в вашем SCM уже создан, единственное, что осталось - это действительно компилировать, упаковывать и развертывать выпуск, что и должно делать mvn deploy.

Если вы предоставили дополнительные параметры (например, для активации профилей) для сборки во время вызова до mvn release:perform, вам также необходимо предоставить их, когда вы запустите mvn deploy.

Используя этот подход, ваш номер версии не изменится, он может оставаться неизменным, поскольку вы просто загружаете то, что уже было помечено как часть mvn release:prepare.

+0

Проблема не в том, что я не могу выполнить то, что вы предложили, я могу это сделать, но когда релиз: выполнить попытки развернуть файл в nexus, он не работает, поскольку файл pom уже существует. – Ravi

+0

Тогда вам действительно нужно поговорить с администратором, чтобы удалить файл. Если этого не сделать, то ваш единственный шанс - увеличить номер версии и заново создать выпуск. В этом случае я часто добавляю индекс к версии. Если ваш неудачный выпуск был 1.2.3, то ваш новый должен быть чем-то вроде 1.2.3-1. Тем не менее, удаление файла pom из Nexus было бы лучшим вариантом. – nwinkler

+0

Если вы не следуете рекомендациям в комментариях к моему ответу выше, вы также можете просто сделать это, хотя он оставит остатки ненужных артефактов в вашем репозитории (хотя вы, возможно, удалили тег). – carlspring

1

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

mvn deploy 

Или откате ваш пресс-релиз:

mvn release:rollback 

И снова это делать, как обычно.

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

Кроме того, ответ @ nwinkler также очень хорош.

+0

Хорошее предложение (удаление артефакта). Я думаю, что 'release: rollback' не откатывает тег или не удаляет развернутый артефакт, верно? Я думаю, что это ручные задачи администратора. – nwinkler

+0

Проблема, которую мы получаем, заключается в том, что администратор нашей связи покинул компанию, и теперь никто не имеет доступа, поэтому мы можем использовать ее как есть, но не можем удалять файлы. – Ravi

+0

Действительно, 'mvn release: rollback' не удаляет тег (который мы все действительно ожидаем от него, он просто возвращает версию проекта (ов)). – carlspring

Смежные вопросы