大規模なビルド プロセス (> 100 モジュール) に Maven を使用しています。外部依存関係をソース管理に保存し、それを使用してローカル リポジトリを更新しています。
ただし、すべてのサードパーティを積極的にダウンロードする必要がないように、中央をキャッシュできるローカル リポジトリに卒業する準備ができています (ただし、ローカル リポジトリからプルすることはできます)。さらに、開発者がワールドを構築する必要がないように、ナイトリー ビルドから内部ビルド アーティファクトを公開したいと考えています。
Nexus と Artifactory を検討しています。どちらかを優先する理由は何ですか? 他に検討すべきことはありますか？
" " からのバイナリの格納についてのみ話しているのであれば、mvn deployどちらもうまくいくと確信しています。
私たちは Artifactory を非常に広範囲に使用し、その過程ですべてのアップグレードを行っています。多くのプロジェクト、多数のスナップショットがデプロイされ、外部リポジトリがプロキシされています。単一の問題ではありません。DB やインデックス作成などで他の人がどのように問題を経験しているかを説明するのは難しいと思います。そのようなことは私たちに起こったことはありません。また、Artifactory ではデータをディスクに保存し、DB のみをメタデータの保存に使用することができます。非常に柔軟です (詳しくはこちらをご覧ください)。
これらのアプリケーションが大きく異なるのは、他のビルド ツールやテクノロジとの統合に対するアプローチです。Nexus と Sonatype は、Maven と m2eclipse にほぼ固定されています。彼らは他のものを無視し、つい最近になって独自の Hudson 統合に取り組み始めました ( Maven 3 webinarを参照してください)。
編集:これは 2017 年現在、もはや真実ではありません。Nexus は他のビルド ツールに対してより大きなサポートを提供しています。
Artifactory は、素晴らしいHudson、TeamCity、Bamboo の統合、およびGradle / Ivyのサポートを提供します。そのため、Sonatype の「コンフォート ゾーン」(Maven、m2eclipse) から一歩踏み出すと、Nexus は何も提供しませんが、Artifactory はすべての主要なビルド ツールを採用し、それらと連携します。
実際、" mvn deploy" ではなく、ジョブの終了時に Hudson からビルド アーティファクトをデプロイできることは大きな違いです。Artifactory Hudson プラグインは、ビルド ジョブが正常に終了した場合にのみ、すべてのアーティファクトを一度にアトミックにデプロイします。" mvn deploy" は各モジュールの後に実行され、ビルド ジョブが途中で失敗した場合にアーティファクトの部分セットをデプロイできます。ジョブの完了時にビルド サーバーからではなく、モジュールの完了時に Maven からデプロイすることは、本当に悪いことです。
ご覧のとおり、Artifactory は「既成概念にとらわれない」と考えていますが、Nexus は「既成概念にとらわれない」と考えており、Maven と Maven アーティファクトのみを考慮しています。
Artifactory をよりアクセスしやすくするもう 1 つの方法は、クラウドベースの Artifactory Online ソリューションです。月額約 80 ドルで、独自の Artifactory インスタンスを使用できます。専用のサーバーを用意する必要はありません。
Artifactory にはシンプルでわかりやすい REST APIがありますが、Nexus でどのように機能するかわかりません。 Edit Nexusには、簡単に使用できるREST API もあります。
要約すると、Maven アーティファクトの基本的なストレージについては、どちらも問題ないと思います。しかし、Nexus は厳密に「Maven リポジトリ マネージャー」であることに終止符を打ちますが、Artifactory は引き続き、あらゆるビルド ツールや CI サーバーからのあらゆる種類のバイナリの一般的な「バイナリ ストレージ」です。
Artifactory についてはわかりませんが、Nexus を使用する理由は次のとおりです。
Artifactory は、ファイル システムとデータベース ストレージ バックエンドの両方をサポートします。ストレージはチェックサムに基づいており、同一のバイナリはリポジトリに何回表示されても一度だけ保存されるため、Artifactory はストレージに関してより効率的になります。このアーキテクチャにより、移動とコピーも非常に安価です (Nexus には、移動/コピー用の REST はありません。ファイル システム上で何かを移動し、レポで修正アクションを実行して、コンテンツが変更されたことを知らせる必要があります)。
もう 1 つの重要な差別化要因は、Artifactory が Hudson および TeamCity と独自に統合されており、デプロイされたアーティファクト、解決された依存関係、およびビルド実行に関連する環境データに関する情報を取得できることです。これにより、ビルドの完全なトレーサビリティが提供されます。
Artifactory はアーティファクトをデータベースに保存します。つまり、何か問題が発生した場合、すべてのアーティファクトが失われます。Nexus は貴重なアーティファクトにフラット ファイルを使用するため、それらがすべて失われる心配はありません。
Artifactory 2 と Nexus 1.3 について最近調査しました。私が見つけた主な違いをここにリストします：
Artifactory を使用する必要があります その最新バージョンは本当に飛躍的でした リポジトリを増分バックアップできます。つまり、すべてのアーティファクトを保存して維持できます 使いやすい Web UI を備えており、セットアップも非常に簡単です。新しいバージョン 2.0 をリリース
すべての政治/宗教はさておき、ライセンスは一部の組織に違いをもたらします。
NexusはGPLになり、AGPLv3になり、Eclipse Public License（EPL）になりました。
Artifactoryは、製品のバージョン2.1の時点でApacheライセンスの LGPLv3ライセンスです。
比較のために、Archivaを検討することもできます。これはApache2.0ライセンスです。
ArtifactoryとNexusはどちらもほぼ同様の機能セットを備えていますが、ArtifactoryのLDAPサポートにより、Nexusよりも魅力的です。NexusもLDAPをサポートしていますが、有料版では:-(
うーん...人工物に関する私の経験はひどいです...しかし、私は比較的初心者なので、塩の粒でそれを取ってください. 私の全体的な不満は、最近 Artifactory にアップロードされた jar ファイルがすぐにインデックス化されないように見えることです (数時間のように)。強制する良い方法もないようです。うまくいくはずだったように見えるさまざまなことを試しましたが、うまくいきませんでした。私はm2eclipseを使用して、antから変換しているプロジェクトに依存関係を追加しています。アーティファクトに追加したばかりの jar を追加しようとすると、セレクターに選択肢として表示されると思いますが、表示されません。
同僚は、nexus をインストールして今のところ気に入っていると言っていましたが、まだ保証できません。IT 部門が見つけ次第、Linux ボックスにインストールしようとしています。