Mavenリリースプラグインが失敗する：ソースアーティファクトが2回展開される
https://stackoverflow.com/questions/4251488
-
27-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
HudsonでMavenリリースプラグインを使用し、リリースプロセスを自動化しようとしています。リリース：準備は正常に動作します。リリースを実行しようとすると、実行すると、ソースアーティファクトを2回リポジトリにアップロードしようとするため失敗します。
私が試したこと、
- Super POMからMavenソースプラグインを含むプロファイルを削除します（機能しませんでした）
- リリースのためのハドソンの目標を-P！アタッチソースリリース：準備リリース：実行します。ソースプラグインが実行されるのを除外すると思いました。 （動作しませんでした）。
- プラグインフェーズをSuper POMの存在しないフェーズに指定しようとしました（機能しませんでした）
- falsとしてfalreaseprofileを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。の2つの実行セクションがあることがわかります 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」アタッチソースを使用していることを確認してください。次に、これらのセクションがマージされます。
ベストプラクティスによると、一貫性を得るには、ビルド>プラグインマネージメントとプラグインマネージメントのプロジェクトのルートポンでこれを構成する必要があると言います いいえ あなたの子供の中で。子供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のいくつかのバージョンでリリースビルドを使用してリリースビルドを使用してアーティファクトを展開する場合、リリースアーティファクトを1回アップロードできるSonatype Nexusリポジトリにアーティファクトを展開する場合、ソースとJavadocジャーが2回展開されるということです（完全に合理的な動作です）、2回目のアップロード試行が拒否されたときにビルドが失敗します。ああ！
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を2回生成および展開します。
Maven Issue Trackerを正しく読んだ場合、これらのバグは、この記述の時点で修正される予定ではありません（Burned 3.4.0リリースはおそらくこれらに影響を与えました）。
私のPOMへの複雑な微調整の代わりに、私の簡単な回避策は、Mavenバージョン3.2.1に戻ることでした。
同じ問題にぶつかっただけで、少し分析しました。 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を2回アップロードしようとしていました。
指摘されているように qualidafial コメントで、設定 performRelease=false 代わりに、同じファイルの2つの添付ファイルのいずれかを省略します。
どうやってアイデアがありません プラグインを展開します （または他のプラグイン）はこのプロパティを使用します。
このパラメーターを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> すべてのPOMSにラインすると、エラーメッセージなしでリリースが機能するように見えます。
私はしばらくこの問題に苦労してきましたが、ついにインフラストラクチャでそれを解決することができました。ここでの答えは私を助けませんでした。ソースプラグインの目標の複数の実行がなく、構成は私たちには問題ないように思えたからです。
私たちが見逃したのは、ソースプラグインの実行をフェーズにバインドすることでした。ラインを含むBaeによる例を拡張します <phase>インストール< /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>
解決策はこの答えにあると思います ここ ;さまざまなプラグインがJARの目標 /アタッチソースの実行を呼び出しているようです。実行の特定のフェーズにバインドすることにより、このフェーズでのみプラグインを実行するように強制します。
これは走っているときに私に起こっていました
mvn install deploy
代わりに実行することで問題を避けました
mvn deploy
（これはインストールを意味します）。私の場合、1つのアーティファクトのみが2回アップロードされようと試みられていましたが、それは二次的なアーティファクトでした（Maven-Jar-Pluginは、デフォルトのJAR実行によって構築されたものに加えて、二次瓶を構築するためにセットアップされました）。
プロフェムがリリースプラグインにあるとは思わない、あなたが持っていると思う xxx-sources.jar 2回添付されています - そのため、重複したアップロードがあります。なぜPOMを見ることなく、重複した添付ファイルがあるのはなぜ困難ですか。実行してみてください mvn -X 誰が添付されるかをログに確認します xxx-source.jar 別の時間。
いずれにせよ、Nexusの優れた回避策には、リリースを数回アップロードできるステージングリポジトリがあります。すべての準備ができたら、ステージングリポジトリを閉じる/宣伝するだけです。を確認します Sonatype OSSセットアップ 例として。
同じ問題がありました。基本的に、エラーメッセージは、アーティファクトがNexusに2回送信されると発行されます。これは、同じNexusリポジトリに2回、または同じNexus内の異なるリポジトリにまたがる場合があります。
ただし、そのような誤解の理由は異なる場合があります。私の場合、ArtifactはJenkinsのMVN Clean Deploy Build Stepの間に正しくアップロードされましたが、2回目の展開が試行されたときに失敗しました。この2番目の展開は、Jenkins Post Build Step「Artifacts in Maven Repository」で構成されていました。
親と子のPOMのMavenプラグインは実行されないはずです。標準的な慣習に従って、プラグイン管理セクションの親POMの実行/目標ですべてのプラグインを定義します。 Child 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>
そして、子のポンは以下のように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>
削除 <executions> 子からPOMから問題が修正されました。効果的なPOMには、2つの実行が実行され、Nexus Repoへの重複インストールが発生しました。
FWIWこの問題はしばらくの間私たちのビルドを破っていました、そして、答えは態度がありませんでした。代わりに、メインアーティファクトに添付されている（読み取り、リリースされた）アーティファクトのために、Maven-Assembly-Pluginで、一見無害で無害なappassemblyを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>
要約すれば：
アセンブリプラグインは、AssemblyIDを次のように使用します 分類器 したがって、アーティファクトの場合、Maven用語では、その独自のGAV座標の重要な部分です（実際、GAVC座標に似ています-Cは分類器です）。
ファイルの名前 インストール, 展開, 、 また リリース 実際にはこれらの座標から構築されています。それ ターゲットディレクトリに表示されるファイル名と同じではありません. 。そのため、ローカルビルドは良さそうですが、リリースは失敗します。
愚かな要素は、ローカルビルドアーティファクト名のみを決定し、残りの部分で役割を果たしません。それは完全な赤いヒーリングです。
要約の概要： Nexusからの400エラーは、メインアーティファクトと同じ名前を持っていたため、メインアーティファクトと同じGAVC座標を持っていたため、メインアーティファクトと同じ名前を持っていたため、メインアーティファクトと同じ名前があったため、メインアーティファクトの上にアップロードされていたためです。座標：AssemblyIDから自動的に導出された分類器。
これを見つけるための調査は長くて曲がりくねった道でした。
appendAssemblyid
ブール
アセンブリの最終名からアセンブリIDを除外し、分類器なしで結果のアセンブリアーティファクトを作成するようにfalseに設定します。 そのため、現在のMavenプロジェクトのパッケージと同じ形式を持つアセンブリアーティファクトは、このメインプロジェクトアーティファクトのファイルを置き換えます.
- デフォルト値は次のとおりです。
- ユーザープロパティは次のとおりです。
から http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach
余分な太字は私のものです。ドキュメントはここで大きな点滅する警告を持っている必要があります：「これを虚偽に設定し、すべての希望を放棄する」
私は別の問題についてこの答えからいくつかの助けを得ました Maven-Assembly-Plugin：AppandAssemblyidの使用方法ツナキからの説明は本当に助けになりました。
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>
