Maven 릴리스 플러그인 실패 : 소스 아티팩트가 두 번 배포 됨

Maven 릴리스 플러그인 실패 : 소스 아티팩트가 두 번 배포 됨

---

우리는 hudson에서 maven 릴리스 플러그인을 사용하고 릴리스 프로세스를 자동화하려고합니다. release : prepare가 잘 작동합니다. release : perform을 시도 할 때 소스 아티팩트를 저장소에 두 번 업로드하려고 시도하기 때문에 실패합니다.

내가 시도한 것,

1. super pom에서 maven 소스 플러그인을 포함하는 프로필 제거 (작동하지 않음)
2. 릴리스에 대한 hudson의 목표를 -P! attach-source release : prepare release : perform으로 지정합니다. 소스 플러그인이 실행되지 않을 것이라고 생각했습니다. (작동하지 않았다).
3. 슈퍼 폼의 존재하지 않는 단계에 플러그인 단계를 지정하려고 시도했습니다. (작동하지 않음)
4. 플러그인 구성, 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

이에 관한 모든 도움을 주시면 감사하겠습니다.

---

을 실행 해보십시오 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"첨부 소스를 사용하는지 확인하십시오. 그런 다음 이러한 섹션이 병합됩니다.

모범 사례에 따르면 일관성을 얻으 려면 자식 poms가 아닌 build> pluginManagement에있는 프로젝트의 루트 POM에서이를 구성해야합니다 . 자식 pom에서 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>

---

이 질문이 오래되었다는 것을 알고 있지만 오늘은 Google 히트 # 1 이었으므로 최신 버전의 maven 3에 적합한 답변을 추가하겠습니다.

증상은 일부 버전의 maven 3으로 릴리스 빌드를 수행 할 때 소스와 javadoc jar가 두 번 배포된다는 것입니다. 릴리스 아티팩트를 한 번만 업로드 할 수있는 Sonatype Nexus 저장소에 maven을 사용하여 아티팩트를 배포하는 경우 완전히 합리적인 동작) 두 번째 업로드 시도가 거부되면 빌드가 실패합니다. 아아!

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 이슈 트래커를 올바르게 읽으면이 글을 쓰는 시점에서 버그가 수정 될 예정이 아닙니다.

내 pom에 대한 복잡한 조정 대신 간단한 해결 방법은 Maven 버전 3.2.1로 돌아가는 것입니다.

---

똑같은 문제를 만난 것만으로도 조금 분석했습니다. mvn release:performrelease.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-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에 줄을 추가했으며 이제 릴리스가 오류 메시지없이 작동하는 것처럼 보입니다.

---

저는이 문제로 한동안 어려움을 겪었으며 마침내 우리 인프라에서 해결할 수있었습니다. 소스 플러그인 목표를 여러 번 실행하지 않았고 구성이 괜찮아 보였기 때문에 여기에 대한 답변이 도움이되지 않았습니다.

우리가 놓친 것은 소스 플러그인의 실행을 단계에 묶는 것입니다. <phase> install </ phase> 줄을 포함하여 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 목표 / 첨부 소스 실행을 호출하는 것 같습니다. 실행을 특정 단계에 바인딩함으로써 플러그인이이 단계에서만 실행되도록합니다.

---

이것은 실행 중 나에게 일어났습니다.

mvn install deploy

대신 실행하여 문제를 피했습니다.

mvn deploy

(설치를 의미 함). 제 경우에는 하나의 아티팩트 만 두 번 업로드하려고 시도했고, 그것은 보조 아티팩트였습니다 (maven-jar-plugin은 default-jar 실행에 의해 빌드 된 것 외에 보조 jar를 빌드하도록 설정되었습니다).

---

나는 probem이 릴리스 플러그인에 있다고 생각하지 않습니다. xxx-sources.jar두 번 첨부 되었다고 생각합니다 . 이것이 중복 업로드 이유입니다. 중복 첨부 파일이있는 이유는 POM을 보지 않고는 알 수 없습니다. 다른 시간 mvn -X에 누가 첨부하는지 로그를 실행 하고 확인하십시오 xxx-source.jar.

어쨌든 Nexus의 좋은 해결 방법은 릴리스를 여러 번 업로드 할 수있는 스테이징 저장소를 갖는 것입니다. 모든 것이 준비되면 스테이징 저장소를 닫거나 승격합니다. 예를 들어 Sonatype OSS 설정 을 확인하십시오 .

---

나는 같은 문제가 있었다. 기본적으로 아티팩트가 Nexus에 두 번 전송되면 오류 메시지가 발행됩니다. 이것은 동일한 Nexus 저장소에 두 번 또는 동일한 Nexus 내의 다른 저장소에 걸쳐있을 수 있습니다.

그러나 이러한 잘못된 구성의 이유는 다를 수 있습니다. 제 경우에는 Jenkins의 mvn clean deploy 빌드 단계에서 아티팩트가 올바르게 업로드되었지만 두 번째 배포를 시도했을 때 실패했습니다. 이 두 번째 배포는 Jenkins 빌드 후 단계 "Maven 저장소에 아티팩트 게시"에서 구성되었습니다.

---

부모 및 자식 poms의 Maven 플러그인은 실행되지 않아야합니다. 표준 규칙에 따라 플러그인 관리 섹션의 상위 pom에 실행 / 목표가있는 모든 플러그인을 정의합니다. 하위 pom은 위의 세부 정보를 재정의해서는 안되지만 실행해야하는 플러그인 (artifactId 및 버전 포함) 만 언급해야합니다.

다음과 같이 부모 pom이있는 maven-assembly-plugin과 비슷한 문제가 있습니다.

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

Removing the <executions> from child pom rectified the issue. The effective pom had 2 executions performed causing the duplicate install to Nexus repo.

---

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.

---

I configured the maven release plug-in with releaseProfile=false and dont execute the source artifacts profile. Which did the trick.

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

참고URL : https://stackoverflow.com/questions/4251488/maven-release-plugin-fails-source-artifacts-getting-deployed-twice