約6か月前に、Mavenリポジトリにないライブラリをプロジェクトに追加するチュートリアルを公開しました。 それは小さなプロジェクトに関するもので、settings.xmlを編集せずにプロジェクトをビルドできるように、pom.xmlにリポジトリタグを直接配置することをお勧めします。
コメントでは、このアプローチはsshikov 、 igor_suhorukov 、 jbaruchおよび他の多くの人々によって批判されました。 そこで、コメントの中で、私はBrian Foxの記事へのリンクを与えられました。この記事には、pom.xmlのリポジトリに何が含まれているかを明確かつ明確に述べています。 2009年の記事ですが、これまでのところ関連性は失われていません。 Habréで翻訳が見つかりませんでした-したがって、私はあなたに自分の翻訳を提供します。
よく聞かれる質問が1つありますが、このテーマに関する私の考えを書面で表現するときが来たので、何度も繰り返す必要はありません。
ここに、この質問があります：リポジトリへのパスを配置する場所：記念碑またはsettings.xmlに ？
短い答え： settings.xml
長い答え： 状況に応じて 。
ここでは、2つのシナリオを検討する必要があります。企業向け（外部からアクセスできないソフトウェア）と、公開されているソフトウェアです。
まずは企業から始めましょう。
エンタープライズ
企業の場合、Nexusなどのリポジトリマネージャーをインストールすることは一般的に受け入れられています。 すべての外部リポジトリのプロキシとして機能し、内部リポジトリも管理します。
Mavenはアーティファクトを検索するときに、探しているものが見つかるまで、pomnitsおよびsettings.xmlで定義されているリポジトリのリストを調べます。 リポジトリマネージャーをpomnikのリポジトリとして指定した場合、そこにアーティファクトが見つからないと、mavenは引き続きセントラルリポジトリを検索するためにロールバックします。
この問題を解決する1つの方法は、中央リポジトリIDを再定義し、そこにリポジトリマネージャのアドレスを入力することです。 このようなソリューションは機能する可能性がありますが、各プロジェクトで手順を繰り返さないために、1つの企業POMファイルでこれを行う必要があります。 Centralを再定義すると、「 Trick-22 」に到達します。 リポジトリへのパスが示されているpompicを見つけるには、このpompicが配置されているリポジトリの場所を知る必要があります。 それはすべて、いずれにせよ、何かが機能するように、このリポジトリをsettings.xmlに追加する必要があるという事実で終わります。
Centralを再定義するだけでは、他にも問題があります。 具体的には、このメソッドでは、プロジェクトの推移的な依存関係にある他のリポジトリへの呼び出しを処理し、要求をそれらにリダイレクトすることはできません。 これは問題を引き起こします：まず、アーティファクトを検索するためにMavenがすべての外部リポジトリを巡回するため、アセンブリの速度が低下します...おそらく、このアーティファクトが存在しない内部リポジトリでもアーティファクトを検索します。 第二に、これは、ある開発者から何かを収集でき、別の開発者からは収集できないことを意味します。 第三に、組織として、アーティファクトがどこから来たのかわからないことがわかります。
組織としてのあなたにとって、ほとんどの場合、すべての開発者がアセンブリ中に同じリポジトリを使用し、すべての要求が1つの制御されたメカニズムを通過すると便利です。 これは、すべての要求をリポジトリマネージャーにリダイレクトするsettings.xmlのmirrorOf *エントリを使用して最も簡単に実現できます。 mirrorOfはコンパイルで定義できません。 優れたセットアップがどのように見えるかの例は、 Nexus Bookのこのセクションにあります。
これらすべての点を考えると、pom.xmlでリポジトリを定義してもあまり役に立ちませんし、基本的には追加の問題が生じるだけです。
上記は、アーティファクトに外部コンシューマがないことを意味します。 そうでない場合は、最初のカテゴリに加えて、2番目に分類されます。 （カテゴリはお互いを除外しません。）
オープンソースプロジェクト
ソフトウェアを公開し、それがあなた以外の誰かによってダウンロードおよび収集される場合、他の点を考慮する必要があります。 すべての依存関係が中央リポジトリにある場合、他に何もする必要はありません。 ただし、アーティファクトを自分のリポジトリ（ 親の親のSNAPSHOTバージョンなど ）またはサードパーティのリポジトリにしか配置できない場合、開発者はコードの構築に問題が発生します。 この場合、この場合にのみ、記憶にリポジトリを追加するのが理にかなっています。 しかし、注意すべき副作用があります。
- 作成したエントリは、ゲル化されたドーナツに永遠にキャストされます。 つまり、URLが後で変更された場合、古いピックアップを使用するすべてのユーザーが壊れたリンクを取得し、作業リンクを手動で検索する必要があります。
- Mavenは依存関係を探すときにそれらを調べる必要があるため、これらの各エントリはそれぞれのアセンブリに分類されます。 現時点では、mavenはリポジトリの依存関係がそれ自体にあることを理解できません（推移性を考慮すると、状況はさらに悪化します）。
ビルド結果がユーティリティ（Nexusなど）であり、依存関係として使用されるコンポーネントではない場合、ピクニックへのリポジトリの追加は多少安全です。 この場合、アセンブリ内のアーティファクトに他の誰かが直接依存する可能性は低く、正しいパスがコードの新しいバージョンに該当する可能性が高いため、上記の懸念は根拠がなくなります。
アセンブリで他の誰かが使用するjarkを公開する場合、それらとCentralリポジトリへの依存関係を投稿することを考慮する必要があります。 これにより、リポジトリまたはURLに何が起こっても、すべてのユーザーが常に使用できるようになり、誤って新しいリポジトリをアセンブリに追加するリスクがなくなります。 同じ理由で、Centralは遅かれ早かれリポジトリの受け入れを停止します。
合計
一番下の行は次のとおりです。 再現可能なアセンブリと組織内で行われていることを適切に制御する必要がある場合は、リポジトリマネージャーを使用し、すべての従業員のsettings.xmlでmirrorOfを設定して、このマネージャーのアドレスを指定します。
ソースコードを外部に提供し、収集しやすくしたい場合は、ピクニックにリポジトリを追加することを検討しますが、URLの選択に軽くアプローチせず、戦略的に考え、常に制御できるURLを使用します。 URLを変更する必要がある場合は、常に404エラーを追跡し、適切なmod_rewriteルールを記述して、将来のビルドで適切なアーティファクトを見つけることができるようにしてください。
PS
そして最後に、私の人生の小さな自転車。 むかしむかし、私は1つの興味深いアイデアの概念実証の作成に参加しました。 すべてがJavaで行われ、顧客の環境にコードをデプロイするのは自然でした。それ以外の場合は、どのような証拠ですか:)。 アセンブリは最高の犬の飼育者の推奨に従って設計され、リポジトリはsettings.xmlで接続され、アーティファクトはNexusに置かれました-すべてはこの記事のようなものです。
しかし、デプロイ中に、編集中はもちろん、アセンブリ中に使用されるsettings.xmlを見ることも許可されないことが突然明らかになりました。 エンタープライズ、セキュリティ、すべてのもの。 そして、私はリポジトリをピクニックに入れなければなりませんでした。 開発用とCI用のリポジトリは異なり、この状況を何らかの形で処理するために、2つのプロファイルを作成しました。1つはデフォルトのCI用リポジトリ、もう1つは設定用のデフォルトとしてマークされた開発用リポジトリです開発者のマシン上の.xml。 感情、私は覚えている、私たちはほとんどその時すすりました。 それで起こります。
UPD。
jbaruchから記事を補足する2つの便利なヒントがありました。ここに追加してください。 もちろん、彼はArtifactoryにdrれていますが、彼には良いアドバイスがあり、何らかの理由でNexusの弁護士は動揺しませんでした。
Artifactoryでpom.xmlからリポジトリを消去します 。 チームの誰かがそれを正しく実行するのが面倒で、混乱に陥った場合、 リポジトリがpom.xmlから削除されるため、CIのビルドがドロップします 。
- 少なくともCIサーバー（およびどこでも良い）ではMaven Wrapperを使用します。 maven-wrapper.propertiesファイルでは、任意のMavenディストリビューションにdistributionUrlを指定できます。これにより、Artifactoryからディストリビューションをダウンロードできます。Artifactoryには、正しいリポジトリを備えた正しいsettings.xmlが既に含まれており、それだけを使用します。 開発者がMavenをそのまま使用してsettings.xmlおよびpom.xmlのリポジトリをダウンロードすることを禁止することはありませんが、CIが正しいリポジトリで配布キットをダウンロードするラッパーを使用する場合、アセンブリは正常に動作し、クラッシュします。何かが間違っている場合。