Maven发布插件失败:源工件被部署两次

时间:2010-11-23 00:00:43

标签: java maven nexus maven-release-plugin

我们正在使用hudson上的maven发布插件并尝试自动执行发布过程。 发布:准备工作正常。当我们尝试执行release:perform时,它会失败,因为它会尝试将源工件两次上传到存储库。

我尝试的事情,

  1. 从super pom中移除包含maven源插件的配置文件(不起作用)
  2. 将hudson的目标指定为-P!attach-source release:prepare release:perform。我认为这将排除源插件被执行。 (没用)。
  3. 尝试将插件阶段指定为超级pom中的某些不存在的阶段。(无法正常工作)
  4. 尝试将插件配置指定为forReleaseProfile为false。 (猜猜是什么?也没用?)
  5. 它仍会吐出此错误。

    [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 个答案:

答案 0 :(得分:65)

尝试运行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以使其与发布配置文件相同。然后这些部分将合并。

最佳实践说,为了获得一致性,您需要在构建&gt;中的项目的根POM中配置它。您的孩子poms中的pluginManagement和 NOT 。在孩子pom中你只需在build&gt;中指定你想使用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 :(得分:23)

我知道这个问题已经过时了,但今天谷歌被#1打了,所以我将添加适合最近版本maven 3的答案。

症状是,在使用某些版本的maven 3进行发布版本时,会将源和javadoc jar部署两次。如果您正在使用maven将工件部署到Sonatype Nexus存储库,该存储库仅允许发布工件上传一次(这是完全合理的行为),当第二次上传尝试被拒绝时,构建失败。哎呀!

Maven版本3.2.3至3.3.9存在错误 - 请参阅https://issues.apache.org/jira/browse/MNG-5868https://issues.apache.org/jira/browse/MNG-5939。这些版本在执行发布时会生成并部署两次源和javadoc jar。

如果我正确地阅读了Maven问题跟踪器,那么在撰写本文时,这些错误都没有安排修复(烧毁的3.4.0版本可能会影响这些)。

而不是对我的pom进行复杂的调整,我的简单解决方法是回到Maven版本3.2.1。

答案 2 :(得分:6)

刚刚遇到同样的问题,我对它进行了一些分析。 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会忽略同一文件的两个附件中的一个。

我真的不知道deploy 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>

我现在将<useReleaseProfile>false</useReleaseProfile>行添加到所有POM中,看起来现在可以在没有错误消息的情况下发布。

答案 3 :(得分:3)

我一直在讨论这个问题,最终能够在我们的基础设施中解决它。这里的答案对我没有帮助,因为我们没有多次执行源插件目标,配置对我们来说似乎很好。

我们错过的是将源插件的执行绑定到阶段。通过Bae扩展示例,包括&lt;行;阶段&gt;&安装LT; / phase&gt; 执行为我们解决了问题:

<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>

我怀疑解决方案在于这个答案here ;不同的插件似乎在调用jar目标/ attach-sources执行。通过将我们的执行绑定到某个阶段,我们强制我们的插件只在这个阶段运行。

答案 4 :(得分:1)

这是我跑步时发生的事情

mvn install deploy

我通过运行来避免了问题

mvn deploy

(表示安装)。在我的情况下,仅尝试将一个工件上载两次,这是第二个工件(除了通过默认jar执行构建的对象之外,还设置了maven-jar-plugin来构建第二个jar)。

答案 5 :(得分:0)

我认为探测器不在发布插件中,我认为你已经连接了xxx-sources.jar两次 - 这就是重复上传的原因。如果没有看到POM,为什么重复附件很难分辨。尝试运行mvn -X并在日志中查看谁再次xxx-source.jar附加。

在任何情况下,Nexus的一个好的解决方法是拥有一个暂存存储库,您可以在其中多次上传版本 - 当一切准备就绪时,您只需关闭/推广暂存存储库。请查看Sonatype OSS setup以获取示例。

答案 6 :(得分:0)

我遇到了同样的问题。基本上,当工件被发送到Nexus两次时会发出错误消息。这可能是同一个Nexus存储库的两倍,甚至是同一个Nexus中的不同存储库。

但是,这种错误配置的原因可能会有所不同。就我而言,在Jenkins的mvn clean deploy构建步骤中正确上载了工件,但是在尝试第二次部署时失败了。第二次部署是在Jenkins post构建步骤“在Maven存储库中发布工件”中配置的。

答案 7 :(得分:0)

父母和子女朋友的Maven插件不应该执行。按照标准惯例,在插件管理部分的父pom中定义所有具有执行/目标的插件。 Child pom不应该重新定义上面的细节,但只提到需要执行的插件(带artifactId和版本)。

我的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>

从子pom中移除<executions>可以解决问题。 有效的pom执行了2次执行,导致重复安装到Nexus repo。

答案 8 :(得分:0)

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.:

    <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:

  1. the assembly plugin uses the assemblyId as the classifier for 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).

  2. the name of the file installed, deployed, or released is 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.

  3. 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.

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.

The investigation to find this was a long and tortuous path the answer was right there all along in the docs for 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.

From 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 appendAssemblyId The explanation there from tunaki really helped.

答案 9 :(得分:0)

TL; DR

如果无法修改父pom,则禁用ID为attach-sources的执行可以解决此问题。

-

此答案是@Bae答案的补充:

https://stackoverflow.com/a/10794985/3395456

我的问题是相同的,运行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,以避免重复的绑定。但是,如果由于无法更改父pom而无法删除它,该怎么办?

有一种方法可以禁用一个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>

参考: Is it possible to override executions in maven pluginManagement?

答案 10 :(得分:0)

我遇到了类似的问题。神器被部署了两次,结果构建失败。

经过检查,发现问题出在Jenkins Script中。 settings.xml被调用了两次。喜欢:

sh“ mvn -s settings.xml干净部署-s settings.xml部署-U .....

引起问题的原因。 更新了此行,它就像一个魅力:

sh“ mvn clean clean -s settings.xml -U .....

答案 11 :(得分:0)

nexus thix 配置对我有用

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-release-plugin</artifactId>
  <configuration>
    <useReleaseProfile>false</useReleaseProfile>
  </configuration>
</plugin>

答案 12 :(得分:-3)

我使用releaseProfile = false配置了maven release插件,并且不执行源工件配置文件。哪个做了伎俩。

<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>