Плагин релиза Maven завершается неудачно: исходные артефакты развертываются дважды
Мы используем плагин Maven Release для Hudson и пытаемся автоматизировать процесс выпуска. Релиз: подготовить, работает отлично. Когда мы пытаемся сделать выпуск: выполнить, он терпит неудачу, потому что пытается дважды загрузить исходный артефакт в хранилище.
Вещи, которые я пытался,
- удаление профиля, который включает плагин maven source из супер-помпа (не работает)
- указание целей для hudson для выпуска как -P!attach-source release:prepare release: execute. Что я думал, что исключит плагин исходного кода от выполнения. (не работал).
- попытался указать фазу плагина для некоторой несуществующей фазы в супер-помпе. (не работает)
- попытался указать конфигурацию плагина для forReleaseProfile как false. (угадайте что?? не сработало тоже)
Это все еще выплевывает эту ошибку.
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xx.xx.xx:8081/nexus/content/repositories/releases//com/yyy/xxx/hhh/hhh-hhh/1.9.40/hhh-hhh-1.9.40-sources.jar
[INFO] 57K uploaded (xxx-xxx-1.9.40-sources.jar)
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [DEBUG] Checking for pre-existing User-Agent configuration.
[INFO] [DEBUG] Adding User-Agent configuration.
[INFO] [DEBUG] not adding permissions to wagon connection
[INFO] Uploading: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases//com/xxx/xxxx/xxx/xxx-xxx/1.9.40/xxx-xxx-1.9.40-sources.jar
[INFO] [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Error deploying artifact: Authorization failed: Access denied to: http://xx.xxx.xx.xx:8081/nexus/content/repositories/releases/com/xxx/xxx/xxx/xxx-config/1.9.40/xxx-xxx-1.9.40-sources.jar
Любая помощь по этому поводу будет очень признательна.
13 ответов
Попробуйте запустить mvn -Prelease-profile help:effective-pom, Вы обнаружите, что у вас есть две секции исполнения для maven-source-plugin
Вывод будет выглядеть примерно так:
<plugin> <artifactId>maven-source-plugin</artifactId> <version>2.0.4</version> <executions> <execution> <id>attach-sources</id> <goals> <goal>jar</goal> </goals> </execution> <execution> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin>
Чтобы решить эту проблему, найдите везде, где вы использовали maven-source-plugin и убедитесь, что вы используете "id" attach-sources, чтобы он совпадал с профилем релиза. Тогда эти разделы будут объединены.
Согласно рекомендациям, для обеспечения согласованности вам необходимо настроить это в корневом POM вашего проекта в build > pluginManagement, а НЕ в дочерних poms. В дочернем pom вы просто указываете в build > plugins, что хотите использовать maven-source-plugin, но не предоставляете никаких исполнений.
В комнате pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<!-- This id must match the -Prelease-profile id value or else sources will be "uploaded" twice, which causes Nexus to fail -->
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
В дочернем pom.xml:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
</build>
Я знаю, что этот вопрос старый, но сегодня он стал хитом №1 в Google, поэтому я добавлю свой ответ, подходящий для последних версий maven 3.
Симптом заключается в том, что исходные файлы и javadoc-файлы развертываются дважды при выполнении сборки выпуска с некоторыми версиями maven 3. Если вы используете maven для развертывания своих артефактов в репозитории Sonatype Nexus, который позволяет загружать артефакт выпуска только один раз (что вполне разумно), сборка завершается неудачно, когда вторая попытка загрузки отклонена. Argh!
В версиях Maven с 3.2.3 по 3.3.9 есть ошибки - см. https://issues.apache.org/jira/browse/MNG-5868 и https://issues.apache.org/jira/browse/MNG-5939. Эти версии генерируют и разворачивают исходники и javadoc jar дважды при выполнении релиза.
Если я правильно прочитал средство отслеживания проблем Maven, то эти ошибки не запланированы для исправления на момент написания этой статьи (вероятно, на них повлиял сгоревший выпуск 3.4.0).
Вместо сложной настройки моего pom, мой простой обходной путь должен был вернуться к Maven версии 3.2.1.
Просто столкнувшись с той же проблемой, я немного проанализировал ее. mvn release:perform оценивает файл release.properties, затем извлекает тег во временную директорию и вызывает там что-то вроде
/usr/bin/mvn -D maven.repo.local=... -s /tmp/release-settings5747060794.xml
-D performRelease=true -P set-envs,maven,set-envs deploy
Я пытался воспроизвести это - вручную проверил тег, созданный release:prepare и призвал это:
mvn -D performRelease=true -P set-envs,maven,set-envs deploy
Я получил тот же результат: он дважды пытался загрузить файл -sources.jar.
Как отметил qualidafial в комментарии, настройка performRelease=false вместо этого пропускает одно из двух вложений одного и того же файла.
Я действительно не знаю, как плагин развертывания (или любой другой плагин) использует это свойство.
Мы можем предоставить этот параметр как конфигурацию для maven-relayse-plugin:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
</plugins>
</build>
Я сейчас добавил <useReleaseProfile>false</useReleaseProfile> линия ко всем POM, и похоже, что освобождение теперь работает без сообщения об ошибке.
Я боролся с этой проблемой некоторое время и наконец смог решить ее в нашей инфраструктуре. Ответы здесь не помогли мне, так как у нас не было многократного выполнения целей исходного плагина, и конфигурация показалась нам подходящей.
Что мы упустили, так это связали выполнение исходного плагина с фазой. Расширение примера Bae, включая строку
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<id>attach-sources</id>
<phase>install</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Я подозреваю, что решение лежит в этом ответе здесь; разные плагины, кажется, вызывают выполнение jar target / attach-sources. Связывая наше выполнение с определенной фазой, мы заставляем наш плагин запускаться только на этой фазе.
Это происходило со мной во время бега
mvn install deploy
Я избежал проблемы, запустив вместо этого
mvn deploy
(что подразумевает установку). В моем случае дважды пытались загрузить только один артефакт, и это был вторичный артефакт (maven-jar-plugin был настроен для создания вторичного jar-файла в дополнение к тому, который был создан при выполнении default-jar).
TL;DR
Отключить выполнение с идентификатором attach-sources устраняет эту проблему, если вы не можете изменить родительские помпы.
-
Этот ответ является дополнением к ответу @Bae:
У меня такая же проблема при запуске mvn -Prelease-profile help:effective-pom, У меня есть две секции исполнения для maven-source-plugin
<plugin>
<artifactId>maven-source-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Ответ, получивший наибольшее количество голосов, просто рекомендует наилучшую практику удаления безымянных (анонимных) executionчтобы избежать дублирования привязки. Но что, если я не могу удалить его, потому что не могу изменить родительский помп?
Есть один способ отключить один execution, не анонимный, а тот с id attach-source. И это также работает для загрузкиxx-javadoc.jar дважды.
Так что под моим pom.xml, Я могу явно переопределить настройки плагинов, отключив выполнение с помощью id attach-source.
<!-- Fix uploading xx-source.jar and xx-javadoc.jar twice to Nexus -->
<!-- try to disable attach-sources, attach-javadocs execution (bind its phase to none) -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>attach-javadocs</id>
<phase>none</phase>
</execution>
</executions>
<inherited>true</inherited>
</plugin>
Ссылки: Можно ли переопределить выполнение в maven pluginManagement?
У меня такая же проблема. По сути, сообщение об ошибке выдается, когда артефакты отправляются в Nexus дважды. Это может быть дважды для одного и того же хранилища Nexus или даже для разных хранилищ в пределах одного и того же Nexus.
Однако причины такой неверной конфигурации могут отличаться. В моем случае, артефакты были загружены правильно во время шага сборки mvn clean deploy в Jenkins, но затем потерпели неудачу при попытке второго развертывания. Это второе развертывание было настроено на шаге пост-сборки Jenkins "Опубликовать артефакты в репозитории Maven".
Плагины Maven в родительских и дочерних помпах не должны иметь исполнения. Согласно стандартному соглашению, определите все плагины с исполнением / целями в родительском pom в разделе управления плагинами. Дочерний pom не должен переопределять вышеуказанные детали, а должен упоминать только тот плагин (с artifactId и version), который должен быть выполнен.
У меня была похожая проблема с maven-assembly-plugin с родительским pom, как показано ниже:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.6</version>
<configuration>
<descriptors>
<descriptor>src/assembly/assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
И у Child pom был maven-assembly-plugin, как показано ниже:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-5</version>
<configuration>
<finalName>xyz</finalName>
<descriptors>
<descriptor>src/assembly/assembly.xml</descriptor>
</descriptors>
</configuration>
<executions>
<execution>
<id>xyz-distribution</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Удаление <executions> от ребенка пом исправили проблему. У эффективного pom было 2 выполненных выполнения, вызывая двойную установку к репозиторию Nexus.
Я не думаю, что пробм в плагине релиза, я думаю, у вас есть xxx-sources.jar прикрепляется два раза - вот почему дубликат загрузки. Почему существует дублированное вложение, трудно понять, не видя POM. Попробуйте запустить mvn -X и проверка журнала, кто присоединяет xxx-source.jar в другой раз.
В любом случае, хороший обходной путь для Nexus - это наличие промежуточного репозитория, куда вы можете загружать релизы несколько раз - и когда все будет готово, вы просто закрываете / продвигаете промежуточное репо. Проверьте настройку Sonatype OSS для примера.
ПОЭТОМУ эта проблема на какое-то время ломала нашу сборку, и ответ был ни один из вышеперечисленных. Вместо этого я по глупости установил для безвредного на вид приложения appendAssemblyId значение false в maven-assembly-plugin для артефакта, который присоединяется (читай развернут, выпущен) с нашим основным артефактом. Например:
<execution>
<id>ci-groovy-distrib</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<descriptorRefs>
<descriptorRef>my-extra-assembly</descriptorRef>
</descriptorRefs>
<!-- This is the BUG: the assemblyID MUST be appended
because it is the classifier that distinguishes
this attached artifact from the main one!
-->
<appendAssemblyId>false</appendAssemblyId>
<!-- NOTE: Changes the name of the zip in the build target directory
but NOT the artifact that gets installed, deployed, releaseed -->
<finalName>my-extra-assembly-${project.version}</finalName>
</configuration>
</execution>
В итоге:
Плагин сборки использует AssemblyId в качестве классификатора для артефакта, следовательно, существенную часть его уникальных координат GAV в терминах maven (на самом деле это больше похоже на координаты GAVC - C является классификатором).
имя файла, установленного, развернутого или выпущенного, фактически строится из этих координат. Это не то же самое, что имя файла, которое вы видите в вашей целевой директории. Вот почему ваша локальная сборка выглядит хорошо, но ваш релиз не удастся.
Глупый элемент определяет только имя локального артефакта сборки и не играет никакой роли в остальной части. Это полная красная сельдь.
Резюме сводки:ошибка 400 от Nexus была вызвана тем, что наш дополнительный прикрепленный артефакт загружался поверх основного артефакта, поскольку он имел то же имя, что и основной артефакт, потому что он имел те же координаты GAVC, что и основной артефакт, потому что Я удалил единственную отличительную координату: классификатор, полученный автоматически из AssemblyId.
Расследование, чтобы найти это, было длинным и извилистым путем, ответ был прямо там в документах для собрания maven:
appendAssemblyId
логический
Установите значение false, чтобы исключить идентификатор сборки из конечного имени сборки и создать результирующие артефакты сборки без классификатора. Таким образом, артефакт сборки, имеющий тот же формат, что и упаковка текущего проекта Maven, заменит файл для этого основного артефакта проекта.
- Значение по умолчанию: true.
- Свойство пользователя: assembly.appendAssemblyId.
От http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html
Лишний жирный мой. Документы должны иметь большое вспыхивающее предупреждение: "Установите это в ложь и оставьте все надежды"
Я получил некоторую помощь из этого ответа о другой проблеме maven-assembly-plugin: Как использовать appendAssemblyId Объяснение там от tunaki действительно помогло.
Я столкнулся с подобной проблемой. Артефакты развертывались дважды, и в результате сборка завершалась неудачно.
Проверил и обнаружил, что проблема была в сценарии Jenkins. Файл settings.xml был вызван дважды. Подобно:
sh "mvn -s settings.xml clean deploy -s settings.xml deploy -U.....
что вызвало проблему. Обновил эту строку, и она сработала как шарм:
sh "mvn clean deploy -s settings.xml -U.....
с конфигурацией nexus thix работал у меня
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
Я настроил плагин релиза maven с помощью releaseProfile=false и не выполняю исходный профиль артефактов. Который сделал свое дело.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<arguments>-P!source-artifacts</arguments>
<useReleaseProfile>false</useReleaseProfile>
<goals>-Dmaven.test.skip=true deploy</goals>
</configuration>
</plugin>
</plugins>
</build>