Maven deploy: deploy-file не работает (409 Conflict), но артефакт загружается успешно

Примечание:

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

Однако другой проект, как pom.xml, так и jar, помещаются в репозиторий.

У меня есть проект в Jenkins, где я использую плагин для продвижения своих артефактов в Maven с помощью цели deploy:deploy-file.

Это работает для нескольких других проектов, которые у меня есть в Maven, но для этого проекта это не удается. Самое забавное, что файл (но не pom.xml) загружается в любом случае. Я проверил это, удалив артефакт из нашего репозитория Maven, а затем запустил рекламную кампанию. Артефакт находится в нашем репозитории после продвижения по службе.

Вот журнал, который я получаю. Сломал лишние длинные линии, насколько я мог:

[workspace] $ /bin/bash -xe /opt/tomcat/apache-tomcat-7.0.27/temp/hudson7357923598740079329.sh
+ FILE_LOC=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive
+ mvn deploy:deploy-file
    -Dversion=0.8.0
    -Dfile=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive/metricsdb-etl.jar
    -DpomFile=/mnt/jenkins/builds/metricsdb-trunk/21/archive/target/archive/pom.xml
    -Durl=http://repo.vegicorp.com/artifactory/ext-release-local -DrepositoryId=VegiCorp
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Command Line Spring Batch Module 0.8.0.CI-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-deploy-plugin:2.7:deploy-file (default-cli) @ metricsdb-etl ---
Uploading: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.jar
2/38 KB   
4/38 KB   
[...]

Uploaded: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.jar (38 KB at 202.2 KB/sec)
Uploading: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.pom
2/7 KB     
4/7 KB   
[...]

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.243s
[INFO] Finished at: Thu Oct 04 14:38:52 CDT 2012
[INFO] Final Memory: 4M/119M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file
    (default-cli) on project metricsdb-etl: Failed to deploy artifacts:
    Could not transfer artifact com.vegicorp.batch.metricsdb:metricsdb-etl:pom:0.8.0 from/to
    VegiCorp (http://repo.vegicorp.com/artifactory/ext-release-local):
    Failed to transfer file: http://repo.vegicorp.com/artifactory/ext-release-local/com/vegicorp/batch/metricsdb/metricsdb-etl/0.8.0/metricsdb-etl-0.8.0.pom.
    Return code is: 409, ReasonPhrase:Conflict. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
failed build [email protected] SUCCESS
Finished: FAILURE

Выход с флагом отладки (-X) находится в Pastebin.

Ответ 1

Я нашел проблему. На самом деле две проблемы:

У меня была только настройка репозитория релизов, и я пытался сохранить релиз моментального снимка в репозитории релизов. Artifactory был настроен на разрешение только выпусков в репозитории выпусков. Это можно изменить в настройках Artifactory, но я решил против этого.
В моем pom.xml другая версия, чем я пытался сохранить. Например, в pom.xml указана версия 2.0, и я пытался сохранить релиз как 2.0.2. По этой причине артефакт отклонил пом (но не банку).

Я нашел параметр Artifactory (для каждого репозитория), который спрашивает, следует ли "Подавлять проверки согласованности POM". Установка этого флажка позволит мне установить версию на одну, но помнить скажет другую.

Мне также пришлось изменить свой файл Maven "settings.xml", чтобы разрешить и репозиторий Release, и Snapshot. Я также должен изменить свой URL в хранилище снимков.

Мы использовали Ivy только некоторое время (у которого нет концепции моментальных снимков), поэтому мы просто помещали материал в репозиторий релизов. Это проект Maven, и разработчик пометил версию в POM как SNAPSHOT.

К сожалению, документация Maven довольно скудная, и до сих пор нет хороших книг по Maven. Еще хуже то, что сообщения об ошибках просто плохие. Что означает "409, ReasonPhrase: Conflict. → [Help 1]"?

Не то чтобы документация по Ivy была намного лучше, но в Ant in Action есть несколько отличных разделов по использованию Ivy.

Ответ 2

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

Ответ 3

Я также сталкиваюсь с этой проблемой, и я обнаружил, что родительский проект не разворачивался в репозитории моментальных снимков. Я запускаю mvn deploy в родительской папке, и проблема решена.

Ответ 4

Да... Несколько причин для той же ошибки. Может быть, это поможет кому-то.

1. Login as Admin to Artifactory
2. Configuration -> Repositories
3. Edit the Local Repository ---> Suppress POM Consistency Checks

Это решает мою проблему... Не уверен. Правильный подход или нет?

Ответ 5

Это сообщение об ошибке тоже. Для меня проблема была в том, что настройка сервера - принимать только релиз, а не SNAPSHOT. После удаления SNAPSHOT из пом, он работал нормально.

Ответ 6

В моем случае файл POM, связанный с файлом jar (внешний, в том же каталоге), имел свою зависимость. Это было автономное репо от третьего лица, которое мне нужно было загрузить в artifactory.

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

Ответ 7

У меня такая же проблема. (TL; DR: решение см. В последней строке)

Во время развертывания от jenkins до Artifactory иногда (magic!) возникла ошибка 409 - конфликт со следующим сообщением об ошибке в журнале Artifactory:

[WARN] (oaeUploadServiceImpl: 239) - Отправка кода ошибки HTTP 409: политика контрольной суммы "LocalRepoChecksumPolicy: CLIENT" отклонила артефакт "gradle -интеграция: com.redacted.java/fooProject/123/foo-123. баночка. Checksums info: ChecksumsInfo {checksums = {SHA-1 = ChecksumInfo {type = SHA-1, original = 'da39a3ee5e6b4b0d3255bfef95601890afd80709', actual = '1459689f0be058f4ecef7e6fe3576f1550a8afda'}, MD5 = ChecksumInfo {type = MD5, original = 'd41d8cd98f00b204e9800998ecf8427e', actual = ' 14c7a498de028d6eb5882b3c698bc456' }}}.

Как может наблюдаться обученный глаз: MD5 # d41d8cd98f00b204e9800998ecf8427e является контрольной суммой для пустого файла или строки.

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

Однако, когда развертывание произошло, файл был там, теперь Artifactory получает контрольную сумму, которая является неправильной и правильно отказывается от файла с кодом ошибки 409.

РЕШЕНИЕ (просто): Сделайте 100% уверенным, что файлы, безусловно, там, прежде чем запускать задание развертывания (добавьте паузу или правильную логику).

Ответ 8

Существует большая вероятность того, что место на вашем удаленном репо заполнено. Проверьте это, прежде чем идти все технические и тратить время. Потрачено впустую 2-3 часа, думая, что это логическая проблема.

Ответ 9

У меня также была эта проблема, и оказалось, что у нас есть правила включения/исключения, установленные в репозитории, в который я пытался развернуть, и мое развертывание не соответствовало этим правилам.

Мое решение состояло в том, чтобы указать развертывание в новом репозитории, в котором **/* использовалось в качестве правила включения (и шаблон из моего другого репозитория в качестве правила исключения, позволяющего разделить их).