Maven release plugin fails : source artifacts getting deployed twice

40,865

Solution 1

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

Solution 2

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.

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 versions 3.2.3 thru 3.3.9 have bugs - see https://issues.apache.org/jira/browse/MNG-5868 and https://issues.apache.org/jira/browse/MNG-5939. Those versions generate and deploy sources and javadoc jars twice when doing a release.

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

Instead of a complex tweak to my pom, my simple workaround was to fall back to Maven version 3.2.1.

Solution 3

Just having hit the same problem, I analyzed it a bit. mvn release:perform evaluates the release.properties file, then checks out the tag in a temporary directory and invokes there something like

/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:prepare and invoked this:

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.

As noted by qualidafial in a comment, setting performRelease=false instead omits one of the two attachments of the same file.

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:

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

Solution 4

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.

Solution 5

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

Share:
40,865
Vanchinathan Chandrasekaran
Author by

Vanchinathan Chandrasekaran

I'm a software consultant with 4 + years of experience. My area of expertise is Java/J2EE. I have worked with some great companies like Wipro Technologies and Accenture and also some startup experience with Foreclosure.com. Right now, I'm working as a Software Engineer for PayPal, a ebay company, at Austin, TX. I have a Master's in Computer science from Texas tech University. On a personal note, I always want to learn something new to keep myself fresh and upbeat

Updated on July 12, 2021

Comments

  • Vanchinathan Chandrasekaran
    Vanchinathan Chandrasekaran almost 3 years

    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.

    Things that I tried,

    1. removing the profile which does include the maven source plugin from the super pom ( did not work)
    2. 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).
    3. tried specifying the plugin phase to some non existent phase in the super pom.(Did not work)
    4. tried specifying the plugin configuration, forReleaseProfile as false. ( guess what?? Did not work too)

    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.

  • qualidafial
    qualidafial almost 13 years
    Downvoted--this is a sledgehammer approach. Only <useReleaseProfile>false</useReleaseProfile> is actually necessary to solve the problem, but you're turning off source artifacts altogether, and skipping tests--that's like turning off all compiler warnings because they annoy you. Also, for completeness I'd like to see an explanation of what the "useReleaseProfile" does and why it helps.
  • Vadzim
    Vadzim over 10 years
    Similar blog post: blog.peterlynch.ca/2010/05/…
  • Rob Johansen
    Rob Johansen over 9 years
    Thanks, @Bae. I was unaware of the effective-pom goal. Your answer helped me track down a problem that I had been fighting for most the day.
  • Rob Johansen
    Rob Johansen over 9 years
    I'm downvoting as well. Skipping tests is never the right answer. In my case, the effective POM showed that one of our projects actually had two executions of the deploy goal. Removing the extraneous execution was the solution.
  • t0r0X
    t0r0X over 7 years
    After serious head banging against the wall... YES, this is the only viable solution, THX! Since we're still locked on JDK 6 for some while, and Maven 3.3.+ requires Java 7, rolling back to Maven 3.2.2 was the only acceptable option.
  • JRA_TLL
    JRA_TLL almost 7 years
    Alternatively, add useReleaseProfile=false as a property.
  • Floresj4
    Floresj4 over 6 years
    I'm finding that attach-sources is still being called switch with this same configuration. Anyone have a clue? Line 640: [INFO] [DEBUG] Goal: org.apache.maven.plugins:maven-source-plugin:3.0.1:jar (attach-sources) Line 660: [INFO] [DEBUG] Goal: org.apache.maven.plugins:maven-source-plugin:3.0.1:jar-no-fo‌​rk (attach-sources)
  • codester
    codester over 5 years
    Had the same issue. Got it resolved. My pom file had maven-source-plugin with the goal of jar-no-fork.But maven root pom file has the same plugin with the goal of jar. Hence the effective-pom generated has both the goals. This causes the duplicate attempt to push sources.jar. Once i removed the jar-no-fork goal in my pom, the default jar goal was the only one left and the build succeeded. For my usage it did not matter if it was jar or jar-no-fork.
  • EricS
    EricS over 4 years
    Seems to be my issue too. As of Maven 3.6.1 now, those issues still not fixed.
  • Leon S.
    Leon S. over 4 years
    Still not fixed in 2019, and the workaround still works. You can find the official packages here: apache.org/dist/maven/maven-3
  • Igor Baiborodine
    Igor Baiborodine over 4 years
    Worked for me, downgraded from 3.6.1 to 3.0.5.
  • Igor Baiborodine
    Igor Baiborodine over 4 years
    Worked for me for version 3.6.1.
  • Enrico Giurin
    Enrico Giurin about 4 years
    it helped me understand that the issue was in the maven-source plugin. I have temporary disabled it and now it works
  • chrisinmtown
    chrisinmtown almost 4 years
    Update June 2020: supposed to be fixed in Maven version 3.7.0
  • tibortru
    tibortru over 3 years
    I had problem performin release:prepare release:perform from jenkins build in order to publish to nexus and issue was that it was doing it twice, first for the artifact second for sources-jar. This answer helped me. +1 I saw people mention reverting back to maven 3.0.5 but that bring up some https protocol errors, so have chosen this solution, and it works on maven 3.6.3
  • user3033075
    user3033075 about 3 years
    I thinks it works. because the plugin configure will be merged by default . The goal will be merged , so as describe on the first answer, will has multi-goals. But the phase configuration will be override. finally , the configuration named attach-sources in the execution section will be overwritten with new phase named none . so the configuration with id attach-sources will be not bind to any build lifestyle.
  • jkratz
    jkratz about 3 years
    Update April 2021: still happening in Maven verion 3.8.1
  • chrisinmtown
    chrisinmtown almost 3 years
    Update June 2021: supposed to be fixed in Maven version 3.8.2. p.s. can you believe how long this has been going on??
  • chrisinmtown
    chrisinmtown over 2 years
    Update Jan 2022: I no longer have access to a Sonatype Nexus repo, would someone please verify that this behavior was fixed in maven version 3.8.2?