mvn -o package
と文句を言うので走れないようです
リポジトリ システムはオフラインですが、アーティファクト com.liferay.portal:util-bridges:jar:6.1.20 がローカル リポジトリで利用できません。
しかし、ローカル リポジトリを確認したところ、そのアーティファクトはそこに存在します。settings.xml ファイルで updatePolicy を never に設定する解決策も試しましたが、うまくいきませんでした。
mvn -o package
と文句を言うので走れないようです
リポジトリ システムはオフラインですが、アーティファクト com.liferay.portal:util-bridges:jar:6.1.20 がローカル リポジトリで利用できません。
しかし、ローカル リポジトリを確認したところ、そのアーティファクトはそこに存在します。settings.xml ファイルで updatePolicy を never に設定する解決策も試しましたが、うまくいきませんでした。
Maven 3.0.x より前のバージョンでは、Maven はローカル リポジトリ内のファイルの発信元を追跡しませんでした。
これは、ビルドの問題を引き起こす可能性があります。特に、(現在は死んでいる) 非常に壊れた java.net2 リポジトリをリストするものをビルドしていた場合は... そのリポジトリがリリースされたアーティファクトを変更しただけでなく (非常に悪質で邪悪な慣行)、アーティファクトを中央のアーティファクトと同じ座標ですが、内容が異なります (信じられないほど悪)
したがって、ビルド作業を行うことができます (中央から commons-io:commons-io:2.0 があったため) ローカルリポジトリを消去し、ビルドが失敗します (java.net2 から commons-io:commons-io:2.0 を取得するため) pom で異なる依存関係を持つ完全に異なるアーティファクトでした)またはその逆。
上記の状況は、Maven リポジトリ マネージャーを使用するための原動力の 1 つです。これにより、ダウンストリームに公開するリポジトリのサブセットと、複数のリポジトリからアーティファクトが解決される順序 (通常はルーティング ルールと呼ばれます) を制御できるためです。
いずれにせよ、maven がリポジトリ アクセス レイヤーとして Aether に切り替えたとき、アーティファクトがどこから来たのかの追跡を開始することが決定されました。
したがって、Maven 3.0.x では、アーティファクトがリポジトリからダウンロードされると、maven は_maven.repositories
ファイルがどこから解決されたかを記録するためにファイルを残します。プロジェクトを構築していて、リポジトリの有効なリストにアーティファクトが解決された場所が含まれていない場合、Maven はアーティファクトがキャッシュにないかのように判断し、アーティファクトの再解決を試みます。 ..
ただし、3.0.x には多くのバグがあります...最も重要なのoffline
は処理方法です...つまり、オフラインの場合、maven 3.0.x はリポジトリがないと見なすため、常に_maven.repositories
ファイルに対して不一致を検出します!! !
Maven 3.0.x の回避策は、ローカル キャッシュからこれらのファイルを削除することです。
$ find ~/.m2/repository -name _maven.repositories -exec rm -v {} \;
副作用として、Maven 3.0.x が提供しようとしている保護が失われます。
良いニュースは、Maven 3.1 には必要な修正が含まれているということです (私たちの行動をまとめてドアの外にリリースすることができれば)。
オフライン モードの場合、Maven 3.1 では_maven.repositories
ファイルが (半) 無視され、オンライン ビルドでそのファイルを無視するオプションもあります (レガシー モードと呼ばれます)。
この時点 (2013 年 6 月 1 日) で、法的要件とテスト要件を満たすリリースをカットする 4 回目の試みが進行中です。 -1 は 3 ~ 4 日後にリリースされます...しかし、uses ビルドが壊れないように 3.1 での変更に十分な時間を与えたいと考えると、もっと長くなる可能性があります (公開された API に変更がありました (事故っぽい - API はサイトと依存関係プラグインによって必要とされる) プラグインの作成者が依存している (必要ではないにもかかわらず) ため、潜在的な可能性がありますが、すべてのベースがカバーされていると思います)
それがあなたの質問に答えることを願っています(そして、あなたが持っていたことを知らなかったかもしれません;-))
シェルスクリプトを介してローカルアーティファクトをインストールしたときに、Ubuntu Linux でこの問題が発生しました。解決策は、ローカルのアーティファクトを削除し、「手動で」再度インストールすることでした-mvn install:install-file
ターミナル経由で呼び出します。