Java Maven 发布插件失败：源工件被部署两次
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4251488/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Maven release plugin fails : source artifacts getting deployed twice
提问by Vanchinathan Chandrasekaran
We are using the maven release plugin on hudson and trying to automate the release process. The release:prepare works fine. When we try to do the release:perform , it fails because it tries to upload a source artifact twice to the repository.
我们在 hudson 上使用 maven 发布插件并尝试自动化发布过程。发布：准备工作正常。当我们尝试执行 release:perform 时，它失败了，因为它尝试将源工件两次上传到存储库。
Things that I tried,
我尝试过的事情，
- removing the profile which does include the maven source plugin from the super pom ( did not work)
- specifying the goals on hudson for release as -P!attach-source release:prepare release:perform. Which I thought will exclude the source plugin from getting executed. (did not work).
- tried specifying the plugin phase to some non existent phase in the super pom.(Did not work)
- tried specifying the plugin configuration, forReleaseProfile as false. ( guess what?? Did not work too)
- 从超级 pom 中删除包含 maven 源插件的配置文件（不起作用）
- 将 hudson 的发布目标指定为 -P!attach-source release:prepare release:perform。我认为这会排除源插件的执行。（不工作）。
- 尝试将插件阶段指定为超级 pom 中的某个不存在的阶段。（不起作用）
- 尝试指定插件配置，forReleaseProfile 为 false。（你猜怎么着？？也没有用）
It still spits out this error.
它仍然吐出这个错误。
[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
Any help regarding this will be really appreciated.
对此的任何帮助将不胜感激。
采纳答案by Bae
Try running mvn -Prelease-profile help:effective-pom.
You will find that you have two execution sections for maven-source-plugin
尝试运行mvn -Prelease-profile help:effective-pom。你会发现你有两个执行部分maven-source-plugin
The output will look something like this:
输出将如下所示：
<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>
<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>
To fix this problem, find everywhere you have used maven-source-pluginand make sure that you use the "id" attach-sources so that it is the same as the release profile. Then these sections will be merged.
要解决此问题，请找到您使用过的所有地方maven-source-plugin，并确保您使用“id”附加源，以便它与发布配置文件相同。然后这些部分将被合并。
Best practice says that to get consistency you need to configure this in the root POM of your project in build > pluginManagement and NOTin your child poms. In the child pom you just specify in build > plugins that you want to use maven-source-plugin but you provide no executions.
最佳实践说，为了获得一致性，您需要在 build > pluginManagement 中项目的根 POM 中配置它，而不是在您的子 poms 中配置它。在子 pom 中，您只需在 build > plugins 中指定要使用 maven-source-plugin 但不提供执行。
In the room pom.xml:
在房间 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>
In the child pom.xml:
在子 pom.xml 中：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
</plugin>
</plugins>
</build>
回答by lexicore
I don't think the probem is in the release plugin, I think you've got the xxx-sources.jarattached two times - that's why the duplicate upload. Why is there a duplicate attachment is hard to tell without seeing the POM. Try running mvn -Xand checking the log for who attaches xxx-source.jaranother time.
我不认为probem 在发布插件中，我认为你已经xxx-sources.jar附加了两次——这就是重复上传的原因。如果没有看到 POM，很难判断为什么有重复的附件。尝试再次运行mvn -X并检查日志以了解谁附加xxx-source.jar了。
In any case, a good workaround on Nexus would be having a staging repository where you can upload releases several times - and when everything's ready you just close/promote the staging repo. Check the Sonatype OSS setupfor an example.
在任何情况下，Nexus 上的一个很好的解决方法是拥有一个临时存储库，您可以在其中多次上传版本 - 当一切准备就绪时，您只需关闭/升级临时存储库。以Sonatype OSS 设置为例。
回答by Vanchinathan Chandrasekaran
I configured the maven release plug-in with releaseProfile=false and dont execute the source artifacts profile. Which did the trick.
我使用 releaseProfile=false 配置了 maven 发布插件并且不执行源工件配置文件。哪个成功了。
<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>
回答by Pa?lo Ebermann
Just having hit the same problem, I analyzed it a bit. mvn release:performevaluates the release.properties file, then checks out the tag in a temporary directory and invokes there something like
刚遇到同样的问题，我分析了一下。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
I tried to reproduce this – manually checked out the tag produced by release:prepareand invoked this:
我试图重现这个 - 手动检查由它产生的标签release:prepare并调用它：
mvn -D performRelease=true -P set-envs,maven,set-envs deploy
I got the same result: It was trying to upload the -sources.jar twice.
我得到了相同的结果：它试图上传 -sources.jar 两次。
As noted by qualidafialin a comment, setting performRelease=falseinstead omits one of the two attachments of the same file.
正如qualidafial在评论中所指出的，设置performRelease=false会省略同一文件的两个附件之一。
I don't really have an idea how the deploy plugin(or any other plugin) uses this property.
我真的不知道部署插件（或任何其他插件）如何使用这个属性。
We can provide this parameter as a configuration to the maven-relase-plugin:
我们可以将此参数作为配置提供给 maven-relase-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>
I now added the <useReleaseProfile>false</useReleaseProfile>line to all the POMs, and it looks like releasing now works without an error message.
我现在<useReleaseProfile>false</useReleaseProfile>将这一行添加到所有 POM 中，看起来现在发布工作没有错误消息。
回答by not2savvy
I had the same problem. Basically, the error message is issued when an artifacts is sent to Nexus twice. This may be twice to the same Nexus repository or even across different repositories within the same Nexus.
我有同样的问题。基本上，当工件被发送到 Nexus 两次时会发出错误消息。这可能是同一 Nexus 存储库的两次，甚至可能是同一 Nexus 内的不同存储库。
However, the reasons for such a misconfiguration may vary. In my case, the artifacts were uploaded correctly during a mvn clean deploy build step in Jenkins, but then failed when a second deploy had been attempted. This second deploy had been configured in a Jenkins post build step "Publish artifacts in Maven repository".
但是，这种错误配置的原因可能会有所不同。就我而言，工件在 Jenkins 的 mvn clean deploy 构建步骤中正确上传，但在尝试第二次部署时失败。第二个部署已在 Jenkins 后构建步骤“在 Maven 存储库中发布工件”中配置。
回答by Tobi Nonymous
I have been struggeling with this issue for a while and have finally been able to resolve it in our infrastructure. The answers here didn't help me, as we didn't have multiple executions of the source plugin goals and the configuration seemed fine to us.
我一直在努力解决这个问题，终于能够在我们的基础设施中解决它。这里的答案对我没有帮助，因为我们没有多次执行源插件目标，而且配置对我们来说似乎很好。
What we did miss out was to bind the execution of the source plugin to a phase. Extending the example by Bae, including the line <phase>install</phase>to the execution resolved the issue for us:
我们错过的是将源插件的执行绑定到一个阶段。扩展 Bae 的示例，包括<phase>install</phase>执行的行为我们解决了问题：
<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>
I suspect the solution lies in this answer here; different plugins seem to be invoking the jar goal / the attach-sources execution. By binding our execution to a certain phase, we force our plugin only to be run in this phase.
我怀疑的解决办法在于这个答案在这里; 不同的插件似乎正在调用 jar 目标/附加源执行。通过将我们的执行绑定到某个阶段，我们强制我们的插件只在这个阶段运行。
回答by Amit Kaneria
Maven plugins in parent and child poms should not have execution. As per standard convention, define all plugin with execution/goals in parent pom in plugin management section. Child pom should not redefine above details, but mention only the plugin (with artifactId, and version) that needs to be executed.
父和子 poms 中的 Maven 插件不应执行。按照标准约定，在插件管理部分的父 pom 中定义所有带有执行/目标的插件。子pom不应该重新定义上面的细节，而只提到需要执行的插件（带有artifactId，和版本）。
I had similar issue with maven-assembly-plugin with parent pom as below:
我与 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>
And Child pom had maven-assembly-plugin as below:
并且 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>
Removing the <executions>from child pom rectified the issue.
The effective pom had 2 executions performed causing the duplicate install to Nexus repo.
<executions>从子 pom 中删除纠正了这个问题。有效的 pom 执行了 2 次，导致重复安装到 Nexus 存储库。
回答by chrisinmtown
I know this question is old but it was google hit #1 today so I'll add my answer appropriate for recent versions of maven 3.
我知道这个问题很老，但它今天在 google 上排名第一，所以我会添加适合最近版本的 maven 3 的答案。
The symptom is that sources and javadoc jars are deployed twice when doing a release build with some versions of maven 3. If you're using maven to deploy your artifacts to a Sonatype Nexus repository that only allows a release artifact to be uploaded once (which is totally reasonable behavior), the build fails when the second upload attempt is rejected. Argh!
症状是在使用某些版本的 maven 3 进行发布构建时，源代码和 javadoc jar 被部署两次。是完全合理的行为），当第二次上传尝试被拒绝时，构建失败。啊！
Maven versions 3.2.3 thru 3.3.9 have bugs - see https://issues.apache.org/jira/browse/MNG-5868and https://issues.apache.org/jira/browse/MNG-5939. Those versions generate and deploy sources and javadoc jars twice when doing a release.
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 两次。
If I read the Maven issue tracker correctly, those bugs are not scheduled for fix as of this writing (the burned 3.4.0 release probably affected these).
如果我正确阅读了 Maven 问题跟踪器，那么在撰写本文时这些错误还没有计划修复（烧毁的 3.4.0 版本可能会影响这些）。
Instead of a complex tweak to my pom, my simple workaround was to fall back to Maven version 3.2.1.
而不是对我的 pom 进行复杂的调整，我的简单解决方法是回退到 Maven 版本 3.2.1。
回答by Rhubarb
FWIW this issue was breaking our build for a while and the answer was none-of-the-above. Instead I had foolishly set the seemingly innocuous appendAssemblyId to false in a maven-assembly-plugin for an artifact that gets attached (read deployed, released) with our main artifact. E.g.:
FWIW 这个问题在一段时间内破坏了我们的构建，答案并非如此。相反，我愚蠢地在 maven-assembly-plugin 中将看似无害的 appendAssemblyId 设置为 false，用于与我们的主要工件连接（读取部署、发布）的工件。例如：
<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>
In summary:
总之：
the assembly plugin uses the assemblyId as the classifierfor the artifact, hence an essential part of it's unique GAV coordinates in maven terms (actually it's more like GAVC coordinates - C is the classifier).
the name of the file installed, deployed, or releasedis actually built from these coordinates. It is not the same as the filename you see in your target directory. That's why your local build looks good, but your release will fail.
The stupid element only determines the local build artifact name and plays no part in the rest of it. It's a complete red-herring.
装配插件使用 assemblyId 作为工件的分类器，因此它是 maven 术语中唯一 GAV 坐标的重要组成部分（实际上它更像是 GAVC 坐标 - C 是分类器）。
安装、部署或发布的文件的名称实际上是根据这些坐标构建的。它与您在目标目录中看到的文件名不同。这就是为什么您的本地构建看起来不错，但您的发布会失败的原因。
愚蠢的元素仅确定本地构建工件名称，而在其余部分中不起作用。这是一个完整的红鲱鱼。
Summary of the summary:The 400 error from Nexus was because our extra attached artifact was being uploaded over top of the main artifact, since it had the same name as the main artifact, because it had the same GAVC coordinates as the main artifact, because I removed the only distinguishing coordinate: the classifier derived automatically from the assemblyId.
摘要摘要：Nexus 的 400 错误是因为我们额外附加的工件被上传到主工件的顶部，因为它与主工件具有相同的名称，因为它与主工件具有相同的 GAVC 坐标，因为我删除了唯一的区别坐标：从 assemblyId 自动派生的分类器。
The investigation to find this was a long and tortuous path the answer was right there all along in the docs for maven-assembly:
调查发现这是一条漫长而曲折的道路，答案一直在 maven-assembly 的文档中：
appendAssemblyId
boolean
Set to false to exclude the assembly id from the assembly final name, and to create the resultant assembly artifacts without classifier. As such, an assembly artifact having the same format as the packaging of the current Maven project will replace the file for this main project artifact.
- Default value is: true.
- User property is: assembly.appendAssemblyId.
appendAssemblyId
布尔值
设置为 false 以从程序集最终名称中排除程序集 ID，并创建没有分类器的结果程序集工件。因此，与当前 Maven 项目的打包格式相同的程序集工件将替换此主项目工件的文件。
- 默认值为：true。
- 用户属性为：assembly.appendAssemblyId。
From http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach
来自http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach
The extra bold is mine. The docs should have a big flashing warning here: "Set this to false and abandon all hope"
额外的大胆是我的。文档在这里应该有一个很大的闪烁警告：“将此设置为假并放弃所有希望”
I got some help from this answer about a different problem maven-assembly-plugin: How to use appendAssemblyIdThe explanation there from tunaki really helped.
我从这个关于maven-assembly-plugin的不同问题的答案中得到了一些帮助：How to use appendAssemblyId tunaki的解释确实有帮助。
回答by EricS
This was happening to me when running
这发生在我身上
mvn install deploy
I avoided the problem by instead running
我通过运行来避免这个问题
mvn deploy
(which implies install). In my case only one artifact was being attempted to be uploaded twice, and that was a secondary artifact (maven-jar-plugin was setup to build a secondary jar in addition to the one built by the default-jar execution).
（这意味着安装）。在我的情况下，只有一个工件被尝试上传两次，这是一个辅助工件（maven-jar-plugin 被设置为除了由 default-jar 执行构建的那个之外，还构建了一个辅助 jar）。
