Maven разных локальных хранилищ для артефактов SNAPSHOT и RELEASE

Возможно ли в Maven настроить различные локальные хранилища для артефактов SNAPSHOT и RELEASE?Maven разных локальных хранилищ для артефактов SNAPSHOT и RELEASE

Причина, по которой я прошу, мы используем Jenkins для непрерывной сборки для нашего проекта. Чтобы обеспечить согласованность (если тот же артефакт построен из разных заданий Дженкинса из-за состояния гонки, мы можем испытать хаотическое поведение) перед началом сборки, мы создаем новый локальный репозиторий для Дженкинса.

Теперь проблема заключается в том, что наш проект огромен, поэтому для каждой сборки нам нужно загружать множество зависимостей из нашего Nexus, но когда вы думаете об этом, нет никаких причин для загрузки каждый раз при новых артефактах RELEASE. Артефакты RELEASE не изменяются от сборки до сборки, например, Spring 4.5, httpclient 4.0, aspectj 1.8.1 одинаково для одной сборки для другой.

Так что для обеспечения согласованности мы не должны иметь только зависимостей SNAPSHOT в репозитории. Если бы у нас могло быть два локальных репозитория для артефактов RELEASE, а для SNAPSHOT - другого, то перед каждым началом сборки мы могли бы удалить репозиторий SNAPSHOT, но повторно использовать локальный репозиторий RELEASE, который бы сэкономил мне гигабайты загрузки из Nexus.

Я знаю, что мы можем сделать конфигурации RELEASE, SNAPSHOT для удаленных репозиториев, возможно ли сделать такую же конфигурацию для локальных репозиториев?

Если это невозможно, как бы вы решили эту проблему.

источник

2017-01-12 posthumecaver

Вы должны использовать отдельные репозитории для моментального снимка и выпуска, конфигурация pom объясняется здесь http://stackoverflow.com/questions/14211697/how-to-configure-maven-project-to-deploy-both-snapshot-and -releases-to-nexus –

В этой статье объясняются удаленные репозитории (это обсуждается при развертывании в Nexus). Это не то, что я хочу, я хочу определить два локальных репозитория, один для SNAPSHOT, один для релизов. Именно так он настроен в settings.xml « c: \ repo». Мне нравится иметь что-то вроде « c: \ repo_snap» и « c: \ repo_rel» или способ создания аналогичного эффекта. – posthumecaver

Извините, я неправильно понял. Я добавил ответ, вы не должны этого делать. –

Ваш Jenkins будет иметь локальную установку maven, которая, в свою очередь, будет иметь локальный репозиторий, это должно быть одинаковым для SNAPSHOT и RELEASE.

После того, как зависимость загружена с Nexus, она будет сохранена локально и не будет загружена повторно, это будет выполнено.

Таким образом, вы должны иметь только большую загрузку с Nexus при первом создании проекта.

источник

2017-01-12 10:55:01

Важно настроить jenkins на пути хранения кэша maven в рабочей области Job, которая гарантирует, что каждое задание может работать независимо друг от друга ... – khmarbaise

Каждое задание будет иметь зависимости, которые уникальны в силу их GAV. Они будут находиться в местном репо, которое очень быстро доступно для доступа. Локальное репо - это кэш для всех рабочих мест. Я всегда настраиваю Jenkins для очистки рабочего пространства на каждой сборке, поскольку в прошлом у меня были проблемы. –

Если вы используете кеш для всех заданий, чем у ваших заданий, возможно, проблема параллелизма, причиной того, что кэш maven не предназначен для одновременного доступа параллельными заданиями ... Кроме того, содержимое кеша может влиять на все ваши задания. ... в частности, если вы выполняете 'mvn install' /' mvn deploy' ... У меня есть сомнения, что ваши проблемы основаны на 'mvn clean' (при использовании старых плагинов и т. д.) или нет .. Я предполагаю, что у вас есть проблемы в вашей сборке maven, что означает еще одну проблему ... Итак, идя по этому пути, ваши сборки не автономны и не могут работать на другом узле и т. д. Таким образом, вы привязаны к своему хозяину – khmarbaise

Maven разных локальных хранилищ для артефактов SNAPSHOT и RELEASE

ответ

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