Maven release plugin fails : source artifacts getting deployed twice

Question

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

Answer 1

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.

Answer 2

I faced similar issue. Artifacts were getting deployed twice and the resultant build was failing.

Checked and found that the issue was in Jenkins Script. The settings.xml was called twice. Like:

sh "mvn -s settings.xml clean deploy -s settings.xml deploy -U .....

which caused the issue. Updated this line and it worked like a charm:

sh "mvn clean deploy -s settings.xml -U .....

Answer 3

Try running mvn -Prelease-profile help:effective-pom. You will find that you have two execution sections for 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>

To fix this problem, find everywhere you have used maven-source-plugin and 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.

Best practice says that to get consistency you need to configure this in the root POM of your project in build > pluginManagement and NOT in 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.

In the room 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:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-source-plugin</artifactId>
    </plugin>
  </plugins>
</build>

Answer 4

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.

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

Answer 5

I don't think the probem is in the release plugin, I think you've got the xxx-sources.jar attached 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 -X and checking the log for who attaches xxx-source.jar another time.

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 setup for an example.

Answer 6

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:

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