内部Mavenリポジトリを維持するためのヒントは？

Question

組織の Maven 2リポジトリを維持することに興味があります。役立つポインタと落とし穴のいくつかを教えてください。

ユーザーがコードをリリースするときにリポジトリから独自のアーティファクトをダウンロードまたは公開するための標準を設定する際に従うべきガイドラインは何ですか？このようなことに対して、どのようなガバナンス/ルールがありますか？開発者向けガイド/ドキュメントには、それについて何を記載していますか？

更新：Nexusを立ち上げ、非常に満足しています。Salのガイドラインのほとんどを順守しており、問題はありませんでした。さらに、Hudson CIサーバーを介したスナップショットアーティファクトの展開アクセスと自動ビルド/展開を制限しました。 Hudsonはすべてのアップストリーム/ダウンストリームプロジェクトの依存関係を分析できるため、コンパイルの問題、テストの失敗、またはその他の違反が原因でビルドが中断した場合、デプロイメントは発生しません。メタデータは2つのバージョン間で変更されているため、Maven2 / Maven3でスナップショットデプロイを行うことに疲れています。 「ハドソンのみ」スナップショット展開戦略はこれを軽減します。リリースプラグインは使用しませんが、バージョンプラグインの周囲にいくつかの配管を書きました。スナップショットをリリースに移動します。また、m2eclipseを使用していますが、Nexusで非常にうまく機能しているようです。設定ファイルからNexusを確認でき、そこからルックアップするためにアーティファクト情報にインデックスを付けることができます。 （これらの設定のいくつかを調整して、内部スナップショットのインデックスを完全に作成する必要がありました。）また、これを行うことに興味がある場合は、標準的な方法としてアーティファクトを含むソースjarをデプロイすることをお勧めします。これをスーパーPOMで構成します。

UPDATE2 ：このSonatypeホワイトペーパーでは、Mavenリポジトリマネージャーの使用目標がそれぞれ異なる導入/成熟のさまざまな段階について詳しく説明しています。

Answer 1

少なくとも4つのリポジトリを持つ1つのnexusサーバーをセットアップすることをお勧めします。人工物はお勧めしません。 nexusの無料バージョンは、3グループ未満の20未満の開発チームにとっては問題ありません。それよりも多くのユーザーがいる場合は、Sonatypeリリースに賛成して支払います。 LDAP統合はそれ自体に対価をもたらします。

1. 内部リリース
2. 内部スナップショット
3. 社内で使用される外部のソースからのコード、または承認されたサードパーティバージョンの内部サードパーティ。 JDBCドライバー、javax。*のもの、およびクライアントとパートナーからのものをここに入れます。
4. 外部プロキシ m2、codehausなどの通常のソースすべての共通プロキシ

Nexusが内部リポジトリに対して以下を実行するように設定します

1. 定期的に古いスナップショットを削除する
2. リリース時にスナップショットを削除
3. インデックスファイルを作成します。これにより、ローカルビルドも高速化されます

これら4つのソースのみを使用する共通のsettings.xmlファイルを用意します。これ以外のカスタマイズが必要な場合は、設定の共通部分を維持するようにしてくださいファイルを作成し、違いを確認するためにプロファイルを使用します。クライアントに独自の設定をロールバックさせないでください。そうしないと、あるマシンでビルドされ、他のマシンではビルドされません。

クライアントに共通のプロキシを提供します。 Nexusでは、一般的なMavenソース（Apache、JBoss、Codehaus）に多数のプロキシを追加し、内部クライアントに公開される単一のプロキシを持つことができます。 。これにより、クライアントへのソースの追加と削除がはるかに簡単になります。

同じリポジトリ内で内部アーティファクトとサードパーティアーティファクトを混在させないでください。 Nexusでは、Web GUIを介して内部リポジトリにjarを追加できます。 JDBCドライバーやその他の外部コードをサードパーティに追加する方法としてこれをお勧めします。 UIは、ほとんどのエンタープライズソフトウェアと比較して、非常に使いやすいです。

distributionManagement タグを使用して、内部スナップショットとリリースリポジトリを定義する共通の親POMを定義します。多くの人がこれをしないように言っているのを知っています。そして、これを行うことにはあらゆる種類の問題があることを自由に認めていますが、クライアントが単一の内部リポジトリにデプロイされるリリースとスナップショットのみを構築する場合は問題ありません。

既存の誤って管理されたMavenリポジトリがある場合、 Legacy という5番目のリポジトリを作成し、リポジトリ全体をそこに配置します。 cronタスクを設定して、1年経った古いファイルをレガシーから削除します。これにより、全員が1年で移行し、pomsを更新できます。

内部アーティファクトの命名規則に準拠しやすいを確立します。 Department.Function.Project のGroupIDと、 componentName 。内部リポジトリの場合、com / org / netと会社名は関係ない可能性があります。また、会社の名前を変更した場合は間違っています。販売、経理、または在庫部門の名前が変更される可能性ははるかに低くなります。

Answer 2

Nexus を必ず使用してください。 ：P

NexusとArtifactoryの両方を使用しました。 Nexusのインターフェースは、はるかに堅牢であり、より多くの設定が可能です。もちろん、 Sonatype によって記述されています、Mavenのほとんどすべてをうまく表現します。

とはいえ、Artifactoryはまともで実用的です。

• NexusとArtifactoryのレビュー
• ああ！もちろん、ここではその問題に関するSOの質問があります。
• Sonatypeは機能の比較を行います
• jFrog（Artifactoryのメーカー）は機能の比較を行います

Answer 3

Artifactory を使用します。

Answer 4

私は自分でArtifactoryを使用していますが、ユーザーインターフェイスと展開/保守の容易さを気に入っています。ただし、Nexusは使用したことがないため、適切な機能比較を実際に行うことはできません。

Artifactoryについて私が本当に気に入っている点を次に示します（Nexusにもこれらの機能があるかもしれないことに注意してください）：

1. 素敵なWeb 2.0インターフェース。
2. ローカルのMavenリポジトリーをインポートして、作業を開始できるようにします。
3. セキュリティのために既存のLDAPサーバーと簡単に統合できます（資格情報を保存する単一のリポジトリの大ファンです）。

実際には2つの主要なMavenリポジトリー実装しか存在しないことを考えると、正しい選択をしたことを本当に確認したい場合は、両方を試して、どちらが良いかを自分で決めることをお勧めします。

Answer 5

おそらくこれは明らかですが、再現性のために、開発者はアーティファクトを上書きするべきではなく、新しいバージョンである必要があります。

これは、アップストリームリポジトリにも適用されます。 Apache-commonsバージョン1.2.3をダウンロードする場合、それを再度ダウンロードしないでください。修正は、既存のバージョンには適用されず、後のバージョンから行われます。

Answer 6

他に考慮すべきこと：

http://archiva.apache.org/

Answer 7

オリジナルの質問（M2リポジトリを構築する際に考慮すべき技術的な問題）として、管理者ごとにリポジトリと管理ユーザーを閲覧するための読み取り専用ユーザーを作成することをお勧めします-管理者ではないすべてのユーザーのユーザーのみ）。 さらに、バックアップイメージを定期的に生成することをお勧めします（おそらく1日1回？）。リポジトリが大きい場合、または時々独自のアーティファクトをインストールする場合の両方で非常に重要です。

最後になりましたが、新しいリモートリポジトリを追加するときは、包含/除外フィルターを追加して、リポジトリ内のアーティファクトルックアップをより迅速に行う必要があります。

考慮すべき問題は他にもたくさんありますが、これらはMaven内部リポジトリを管理しているときに遭遇した主要な問題です。

記録のために、NexusとArtifactoryの両方を使用しています。 Nexusは非常にシンプルで機能的ですが（Ubuntuでのインストールプロセスに問題があることがありますが）、その無料版はArtifactoryのコミュニティ（無料）エディションと競合することはできません。 Artifactoryの素晴らしいWeb 2 UIを除き、セキュリティ管理、定期的なバックアップ、アクセシビリティの問題などの主要機能はNexusの機能をはるかに超えています。