6

私の顧客は、プロジェクトの本番環境で使用されるすべてのサードパーティライブラリ（JARファイルなど）のより整理されたインベントリを必要としています。私は彼らのJavaベースのプロジェクトの多くに関わっています。それらのインベントリは過去に一貫して維持されておらず、現在使用されているすべてのライブラリ（かなりの数があります！）を考慮し、新しいライブラリをビルド環境に導入するための構造化されたプロセスを実施する時が来ました。

ビルドプロセスでMavenとArtifactoryを使用して、バイナリライブラリのリポジトリを管理し、一時的なライブラリの依存関係を処理するツールの機能を活用するというアイデアを提案してみました。顧客は、Artifactoryサーバーを維持し、Mavenの基本を学ぶための作業が増えると考えているため、提案に抵抗しています。

現在、彼らのJavaプロジェクトはすべてAntスクリプトを使用して構築されています。推移的な依存関係は、主に試行錯誤によって管理されます。現在使用されているライブラリのインベントリは手作業で維持され、バイナリはSubversionリポジトリに保存されます。顧客はこれを改善する必要があることを認識していますが、現在の改善提案には、よりアドホックな「手作業で管理する」アプローチが含まれています。

MavenとArtifactoryの組み合わせは、Javaライブラリ管理のニーズに対応する実用的な既成のソリューションであることをお客様に納得させたいと思います。MavenとArtifactoryの機能と長所について顧客向けのプレゼンテーションを作成するために使用できる文献/資料を誰かに教えてもらえますか？

これで私を助ける他の議論/提案/その他もありがたいです。

4

1 に答える 1

8

MavenとArtifactoryの組み合わせは、Javaライブラリ管理のニーズに対応する実用的な既成のソリューションであることをお客様に納得させたいと思います。

コメントで指摘されているように、依存関係管理の恩恵を受けるために、顧客は必ずしもMavenを完全に採用する必要はありません。既存のAntスクリプトをMavenAntタスクまたはIvyを使用するように適合させることができます。これはそれほど怖くないかもしれず、すでにいくつかの痛みを取り除きます。

Mavenが依存関係を管理する方法に関して、私は簡単に次のように説明します。

  • アーティファクトは座標（groupId、artifactId、バージョン）によって識別されます。
  • これにより、標準化されたディレクトリ構造（リポジトリ）を使用してそれらを保存できます。
  • 依存関係はJAR以上のものです。推移的な依存関係の解決などを可能にするPOMを備えたJARです。

そして、そのような依存関係管理ソリューションの利点は次のとおりです。

  • 依存関係の混乱はなく、一意に識別されます（「それはどのバージョンですか？」シンドロームはもうありません）
  • VCSにバイナリデータがなくなりました（チェックアウトが速くなり、スペースが少なくなります）
  • プロジェクト間でのアーティファクトの再利用が容易になります（電子メールで送信されるjarファイルがなくなります）
  • 推移的な依存関係の解決による管理の容易化

また、パブリックリポジトリに依存したくないため、独自のアーティファクトを保存する必要があるため、エンタープライズリポジトリが必要です。私の個人的な選択はNexusです：

  • これはファイルベースであるため（Artifactoryとは異なり、アーティファクトをデータベースに入れたくない）
  • インストール/使用が簡単だから
  • 管理が簡単だから

Nexusに関するいくつかのリソースを次に示します（申し訳ありませんが、Artifactoryは使用していません）。

念のため、Mavenに関するプレゼンテーション資料を以下に示します。

于 2010-10-07T21:54:59.413 に答える