Maven Javaプロジェクトのビルドユーティリティについて、およびHabréでSonatype Nexusを使用してMavenリポジトリのローカルサーバーを作成する可能性については、すでに述べています（ こことここ ）。 ただし、このテーマに関するレシピは提供されていません。 これは十分に完全な有能な文書の存在で驚くことではない。 サービスの結果として、私は会社でそれを設定しなければならなかった、そしてそれは公式文書からのヒントが完全に適合しないことが判明した。 私はこの問題とそれを解決する方法をコミュニティと共有したいと思っています。 しかし、まず最初に。
なぜこれが必要なのですか？
Mavenリポジトリのローカルサーバー（Sonatype Nexusなど）は、ローカルのMavenアーティファクトを格納するために使用でき、モジュラーアプリケーションを開発するが、パブリックドメインでモジュールを公開しないチームには本当に役立ちます。
さらに、このようなサーバーは、リモートMavenアーティファクトのローカルストレージでも機能します。これにより、すべてのチームメンバーによるリモートアーティファクトのロード時間が大幅に短縮され、外部リポジトリにアクセスできなくなります。 このような使用については、さらに説明します。
最も人気のあるこのようなサーバーは3つあります。
- ソナタイプネクサス
- Apache Archiva
- 工房
Sonatype Nexusをインストールする
この段階では、ドキュメントを安全に守ることができます。私の記憶では問題はありませんでした。 SonatypeのWebサイトには、優れたトレーニングのスクリーンキャストがあります。 インストールプロセスの本質を簡単に説明します。
Nexusを展開するには2つの方法があります。
- コンテナ上のWARファイルとして（例：Apache Tomcat）
- アーカイブを解凍し、手動で開始します（Jettyは内部で使用されます）。 デフォルトのポートは8081です。URL：http：//ホスト：8081 / nexus
原則として、設定なしですでに使用できます（Mavenセントラル、Codehaus、Apacheプロキシリポジトリはすぐに使用可能）が、アクセス権、リポジトリグループを設定し、必要なプロキシリポジトリを追加し、インデックス作成を有効にするなどの意味があります。
Sonatype Nexusをプロキシとして使用するためのMavenの構成
この段階はすでにはるかに曖昧です。 公式ドキュメントが提供するものを見てみましょう。
ここでは、settings.xmlに以下を記述することをお勧めします。
< mirror >
< id > nexus </ id >
< mirrorOf > * </ mirrorOf >
< url > http://host:8081/nexus/content/groups/public </ url >
</ mirror >
* This source code was highlighted with Source Code Highlighter .
同時に、
<repositories>
を使用してpom.xmlプロジェクトでサードパーティのリポジトリが定義されている場合、そのような設定は問題を引き起こす可能性があると正直に言ってい
<repositories>
。 実際、この設定では、Maven は Nexus のみをポーリングします。これは、追加のリポジトリの存在を認識していない場合があります。 私たちのプロジェクトにそのようなリポジトリがあるのはたまたま起こっただけです。 このような状況では、ドキュメントは、そのようなすべてのリポジトリをローカルリポジトリのパブリックグループに追加することを推奨しています。
これは論理的なアドバイスですが、Nexus管理へのアクセスの制限に関連する組織上の問題がいくつかあります。 そのため、たとえば、ビジネスでサードパーティのライブラリを試すために、開発者は管理者を引っ張って、適切なリポジトリをNexusに追加することを強制されます。 しばらくの間、settings.xmlでこのミラーをオフにします-これは別の松葉杖です。
この問題を克服するために使用できる他のオプションは何ですか？ 次の3つが思い浮かびます。
-
<mirrorOf>central</mirrorOf>
ミラーを使用し<mirrorOf>central</mirrorOf>
。
すべてが機能しますが、パフォーマンスとミラーの使用によるトラフィックの節約の利点はほとんどありません。 この場合、 追加のリポジトリはすべて中央よりも早くポーリングされるため、Nexusはメインリポジトリのみをプロキシします。
- Nexusをpom.xmlの各プロジェクトにリポジトリとして追加します。 このオプションは、たとえばpom.xmlに変更を加えることができない場合に他の人や公共のプロジェクトに適していないことに加えて、さらに便利ではありません。 ただし、Nexus_aポーリングはキューで最初に実行できます。
- Nexusをリポジトリとしてデフォルトプロファイルに追加します。 これは、上記のプラスの機能を組み合わせたアプローチです-集中構成と効率的なプロキシ
< profiles >
< profile >
< id > nexus </ id >
< repositories >
< repository >
< id > nexus-repo </ id >
< name > Nexus repo </ name >
< url > http://host:8081/nexus/content/groups/public </ url >
< releases >
< enabled > true </ enabled >
</ releases >
< snapshots >
< enabled > true </ enabled >
</ snapshots >
</ repository >
</ repositories >
< pluginRepositories >
< pluginRepository >
< id > nexus-repo </ id >
< name > Nexus repo </ name >
< url > http://host:8081/nexus/content/groups/public </ url >
< releases >
< enabled > true </ enabled >
</ releases >
< snapshots >
< enabled > true </ enabled >
</ snapshots >
</ pluginRepository >
</ pluginRepositories >
</ profile >
</ profiles >
< activeProfiles >
< activeProfile > nexus </ activeProfile >
</ activeProfiles >
* This source code was highlighted with Source Code Highlighter .
基本的に、この設定では、デフォルトでアクティブなプロファイルを追加し、Nexusを通常のリポジトリとして追加します。 そして、彼は最初にキューに追加されます。
これで、すべてのリクエストが最初にNexusに送信されます。 格納および接続されたプロキシリポジトリで要求されたアーティファクトの可用性に応じて、後者は要求されたアーティファクトを返すか、否定的に応答します。 答えが「いいえ」の場合、Mavenはpom.xmlにリストされたリポジトリーのポーリングを続行し、Maven中央リポジトリーに戻ります。
アプローチの利点
- すべてのプロジェクトに対して一度、1か所で構成可能。
- Nexusに登録されているすべてのリポジトリからのアーティファクトへのアクセスの高速化（追加のリポジトリを含む）。
- pom.xmlに記述されている外部リポジトリがNexusに登録されていなくても、アセンブリのパフォーマンスは損なわれません。
- Nexusの使用を一時的に無効にする機能（
mvn -P !nexus
）。
mvn -s filepath
）が、これはエレガントな解決策ではないようです。
アプローチの欠点
唯一の欠点が明らかになりました-pom.xmlに必要な追加リポジトリを追加するのを忘れる危険があります。 確かに、この欠点は事実上すべてのアプローチ（2番目を除く）に適用され、ローカルNexusリポジトリがない場合にも発生する可能性があることに注意する必要があります。
実際、サードパーティのリポジトリがNexusに追加された場合、Nexusが接続されている開発者にとっては、アセンブリは問題なく機能します。 しかし、Nexusが設定されていない開発者は、Mavenがどの追加リポジトリからアーティファクトを要求する必要があるかを知らないため、プロジェクトをまったく構築できません。
同様の状況は、以前のプロジェクトで作業した後、一部のアーティファクトがローカル開発者リポジトリにキャッシュされている場合に発生する可能性があります。 一般に、この問題では、警戒心を失わないことが重要です。
あとがき
pom.xmlプロジェクトで説明されているすべての追加リポジトリを追加するドキュメントの作成者のアドバイスは、Nexusではキャンセルされていません。 これは、プロキシMavenリポジトリの使用から利益を得るために、本当に最適に行われます。 しかし一方で、提案されたソリューションのアプリケーションはオプションであり、管理者が必要なリポジトリを追加するまで開発者の待ち時間をなくすことができます。
UPD：同様の問題に対処する興味深い記事 に出会いました。