Maven のセントラルリポジトリやリムーブリポジトリ（※）で提供されていないサードパーティ Jar や俺俺ライブラリを pom.xml 上でどう管理するかという話です。 管理の仕方によって、開発者や管理者（環境構築をするようなアーキテクトっぽい人）の仕事が変わってくると思います。
※ http://daipresents.com/2009/maven2_internal_repository_webdav/
方法としては、主に以下の3つがあると思います。
1. ローカルリポジトリに Jar をインストールする
Jar ファイルをローカルのリポジトリに手動でインストールする方法。 以下のコマンドを叩くことで、自分のローカルリポジトリに Jar ファイルがインストールされる。
[bash] mvn install:install-file -Dfile=jarまでの絶対パス -DgroupId=<group-id> -DartifactId=<artifact-id> -Dversion=バージョン -Dpackaging=jar -DgeneratePom=true [/bash]
メリット
- 特になし？
デメリット
- 開発者全員が同じコマンドを叩く必要がある
- ライブラリのバージョンアップ時にも同じ作業が必要
2. インターナルリポジトリを立てる
開発用に新たなリポジトリサーバを立てる。いわゆる社内リポジトリ。 やり方は省略。 http://daipresents.com/2009/maven2_internal_repository_webdav/
メリット
- 開発者自体は特別な操作を必要としない
デメリット
3. system スコープを使う
ライブラリを system スコープのライブラリとして定義して、Jar ファイル自体はプロジェクト内で持つという方法です。 pom.xml には環境依存しないように systemPath を ${basedir} 等を使って定義する。。
[xml]
メリット
- 開発者は特別な操作を必要としない
デメリット
- ライブラリをプロジェクト内で持つ必要がある（バージョン管理システムに含めなければならなかったりして、ファイルサイズが大きくなる）
※Webアプリケーションについて
Webアプリケーションの場合、WEB-INF/lib に Jar ファイルを置くことで自動的にクラスパスに含まれるので、ここに配置してしまうという手もありますが、pom.xml に依存性を書く必要がなくなるので、このライブラリだけ pom.xml に書かれてないみたいな気持ち悪さがあります。 そして、pom.xml に書かれてないと、mvn test 時にクラスパスが通らないという問題もあります。
あと、ライブラリをプロジェクト内で持つ必要がある、というデメリットも当然あります。
まとめ
方法としては、2. か 3. のどちらかかなぁと思います。 自分は管理の簡便性を求めて、3. でやっています。 プロジェクトの規模感で 2. でやる方法もありかなぁと思います。
