問題タブ [maven-metadata]

Maven では、通常、依存関係は次のように設定されます。

頻繁にリリースされるライブラリを使用している場合、 <version> タグを常に更新するのはやや面倒です。(リポジトリから) 最新の利用可能なバージョンを常に使用するように Maven に指示する方法はありますか?

Maven2を使用していますが、リポジトリにプラグインが見つからないようです。次のようなエラーが発生します

リポジトリメタデータ：'org.apache.maven.plugins'がリポジトリに見つかりませんでした：myrepo

ここで、myrepoは私のリポジトリの名前です。

私の質問は、Mavenがプラグインの場所をどのように知っているかということです。エラーにはメタデータへの参照がありますが、どのメタデータがどこでどのような形式をとる必要がありますか？私はこれまでドキュメントを探すのにあまり運がありませんでした...

（中央リポジトリを使用する簡単な答えには興味がありません。myrepoが機能しない理由を知りたいです。）

ありがとう！

私がやりたいことは、ローカル リポジトリにあるアーティファクトごとに Maven に「maven-metadata.xml」をダウンロードさせることです。

デフォルトの Maven の動作は、リモート リポジトリからメタデータのみをダウンロードすることです (この質問を参照してください)。

私がそれをしたい理由：

現在、ビルド マシンでリモート リポジトリを実行しています。リモート リポジトリとは、Maven プロジェクトをビルドするために必要なすべての依存関係を含む、ビルド マシンにあるディレクトリを意味します。Nexus のようなリポジトリ マネージャーを使用していないことに注意してください。リポジトリは、ビルド マシンにアップロードしたローカル リポジトリの単なるコピーです。

ただし、私のローカル リポジトリには「maven-metadata.xml」ファイルが含まれていなかったため、これらのメタデータ ファイルもビルド マシンのリポジトリにありません。中央リポジトリからメタデータ ファイルを取得できれば、作業中のリモート リポジトリをビルド マシンにアップロードできます。

pom.xml からの次のリポジトリ URL を指定すると、リポジトリで利用可能な spring と hibernate の最新バージョンをどのように判断できますか? http://repo1.maven.org/maven2

アーティファクトの maven-metadata.xml が表示されないという問題があります。これが私が取り組んでいる環境です：Apache Archiva、Ivy、ant。

問題: Web UI フォームを使用してアーティファクトをデプロイしているときに、maven-metadata.xml のすべての属性を表示できます。

しかし、コマンド プロンプト (ant publish-latest -Dversion=1.0.3) でアイビーを介してアーティファクトをデプロイすると、アーティファクトは最新の変更で正常に更新されますが、アーティファクトの maven-metadata.xml には最新のタイム スタンプの属性がありません。

これが私のant publish-latestターゲットです：

この問題について助けてください。私は最新のアーティファクトを取得する過程でこの時点で攻撃しました。

最近、ビルド環境に 2 台目のビルド マシンを追加したところ、非常に奇妙なビルド エラーが時々発生するようになりました。

AとBの2 つの別個の Maven ビルド マシンがあり、それぞれ Maven 2.2.1 を実行し、共有の Nexus 1.5.0 リポジトリ マネージャーと通信しています。私の問題は、以前にAによってビルドされ、Nexus にアップロードされた共通の依存関係 ' acme-1.0.0-SNAPSHOT 'の新しいバージョンのダウンロードを拒否するため、 Bでのビルドが失敗することがあるということです。

両方のマシンのローカル リポジトリを調べたところ、リポジトリ メタデータに奇妙な点がいくつかありました。

マシンAの acme\1.0.0-SNAPSHOT\maven-metadata-nexus.xml:

マシンBの acme\1.0.0-SNAPSHOT\maven-metadata-nexus.xml:

Nexus の acme/1.0.0-SNAPSHOT/maven-metadata.xml では:

私がメタデータ ファイルを正しく解釈している場合 (オンラインのドキュメントは乏しい)、マシンB は、マシン Bがビルドしてから 6 日後にマシンAが最後にビルドしたという事実にもかかわらず、(buildNumber に基づいて) acme依存関係の新しいバージョンがあると信じているようです。(タイムスタンプに基づく)。また、Nexus は一般的に正しい buildNumber を認識していないようです。

このような状況がどのように発生する可能性がありますか? 一貫性のないメタデータが原因でビルドが失敗しないようにするにはどうすればよいですか? 似たような経験はありませんか？

重要事項:

• 両方のビルド マシンには、updatePolicy が「常に」である settings.xml ファイルがあります。
• Nexus には、 Aによってビルドされた新しいバージョンのacmeが実際にあります。Bは単にダウンロードを拒否します。
• Nexus にアップロードするマシンはAとBだけです。
• 両方のサーバーが同じシステム時間を共有します。
• 関連するすべてのプロセスには、必要に応じて更新できるように、メタデータ ファイルへの書き込み権限があります。
• この動作を説明する未解決の Maven または Nexus の問題は見つかりませんでした。
• 私たちの CI サーバー (Atlassian Bamboo) は、同じアーティファクトのビルドが同時に発生するのを防ぎます。そのため、Nexus へのアップロード中に競合状態が発生する可能性はほとんどありません。

2.2.1からMaven3.0.1への移行をテストしています。

デプロイフェーズを除いて、すべてのフェーズが正常に実行されます。

2.2.1で最初に実行したときは、すべて正常に実行されます。

次に、3.0.1に切り替えて同じコマンドを実行すると、最上位のmaven-metadata.xmlファイルを除いてすべて正常に動作します。Mavenがそのファイルをアップロードしようとすると、httpエラー：500が発生します。

以下のログで気付いた場合：

これは失敗します：

しかし、これは成功します：

この問題に関する情報があまり見つからないことに驚いています。それからまた、Maven3は約8か月間しかリリースされていません。

私には関係ないと思われる次の2つの問題が見つかりました：_http：//maven.40175.n5.nabble.com/Created-MSITE-531-Site-deployment-fails-on-googlecode-repository-unnecessary- path-element-in-WebDAV--td3307584.html

_http：//maven.40175.n5.nabble.com/Moved-WAGON-319-Site-deployment-fails-on-googlecode-repository-unnecessary-path-element-in-WebDAV-UR-td3308501.html

また、「アーティファクトリー」から古いアーティファクトを完全に削除して、再度デプロイしてみました。

ここで誰かが私を正しい方向に向けてくれることを願っています。

以下に関連情報を貼り付けています。

前もって感謝します。

コンソール出力の関連部分は次のとおりです。

-Xスイッチを使用して実行した場合のスタックトレースは次のとおりです。

私はApache Maven 3.0 Nexus Open Source Edition、バージョン：1.8.0.1を使用しています

これは私の pom.xml の一部です

これは非常に単純なプロジェクトです。私がする時

すべてが正常に実行されます:

今、私はhttp://myrepo/nexus/content/repositories/.../maven-metadata.xmlをダウンロードします。 これは次のようになります。

私の最新およびリリースされたばかりのバージョンは、「最新」および「リリース」としてマークされていません。

今、私は Nexus WebUI 内で「メタデータの再構築」を行います。この後、メタデータを再度ダウンロードします。今はこんな感じ

これは nexus または maven のバグのように見えますか? 誰かがこれに対する解決策を持っていますか?

私の maven-metadata.xml には、Nexus の正しい RELEASE バージョンがありません。Nexus 1.8.0.1 を使用しています。maven-release-plugin を使用して Nexus にデプロイすると、ログにメタデータが更新されたことが示されます。また、正しいバージョンがバージョンのセットに追加されていることもわかります。<release>バージョンが間違っているだけです。

Nexus UI を使用してファイルを再作成しようとしましたが、うまくいきませんでした。

乾杯、

ジェフ

Maven2からMaven3に移行してから問題が発生しています。「-U」フラグを使用してビルドすると、アーティファクトの更新のチェックにMaven2と比較してかなり時間がかかります。Maven2で何が行われたかわかりません。この場合ですが、Mavenはすべてのmaven-metadata.xmlを何度もダウンロードしているようです。

私は次のMavenバージョンを使用しています：

「mvndependency：resolve -U」の出力をリダイレクトし、 http： //lenni.info/dependency_resolve.logにアップロードしました

その中で、私が構築しているプロジェクトには合計で142の依存関係（推移的な依存関係を含む）がありますが、ログには6400行あります。これはたくさんのようです。

例：ログを分析する場合

mtcommonsのmaven-metadata.xml（内部プロジェクト。ほとんどすべての内部アーティファクトによって参照されます）が714回ダウンロードされていることがわかります。現在、3つのリポジトリ（Nexusによって管理されている）があり、すべてのリポジトリをチェックする必要があることは理解していますが、714回はあまりにも頻繁に思えますね。Maven3は、単一のビルド内でもメタデータをキャッシュしないため、同じファイルを複数回再ダウンロードするようです。

これがMaven3のデフォルトの動作であるとは本当に信じられませんが、おそらくNexusでも、構成エラーが発生している可能性があります。しかし、徹底的な検索とたくさんのグーグルの後、私は気が遠くなりました。

ビルドごとに1回だけMavenにメタデータファイルをダウンロードさせるにはどうすればよいですか？