Mavenプロジェクトで3rdパーティJARを扱う方法
最近北欧よりの記事ばっかりだったので、Mavenネタを1つ。Mavenプロジェクトでスマートに3rdパーティJARを扱う2通りの方法を説明する。
Mavenの最大の利点の1つに、依存JARライブラリがローカルPC上の中央リポジトリで管理され、プロジェクト毎の管理が必要ないという特徴がある。しかし、利用したいライブラリがオープンソース︵OSS︶でなかったり、OSSでも非常にマイナーなものだったりすると、リモートリポジトリに無くて使えない。 この場合によく説明されるのが、以下のようにしてJARをローカルリポジトリに手動でインストールする方法だが、チームで開発しているときに、この作業をメンバひとりひとりにやらせるのは非常に格好が悪い。
以下2つのいずれかの方法を採用すれば、もっとスマートに3rdパーティJARを扱うことができる︵個人的には、2番目の方法がオススメ︶。 (1) プロジェクト内にMavenリポジトリを作る (2) system スコープと ${basedir} を使う
(1) プロジェクト内にMavenリポジトリを作る まず最初に紹介するのは、プロジェクトの中にリモートにあるのと同じMavenリポジトリを作ってしまう方法。︵ここでは、Sunが提供する activation.jar を3rdパーティJARの例として説明する︶
(2) system スコープと ${basedir} を使う もう1つの方法は、pom.xml の依存JAR設定にある system スコープと変数 ${basedir} を利用する方法。
(1)、(2)どちらの方法にしても、JARをSubversionにつっこんでいる点ではAnt時代と同じだが、プロジェクトの管理はMavenに一元化され、最初に mvn eclipse:eclipse をやればいいだけになる。mvn install:install-file を各自が実行しなければいけなかったり、mvn eclipse:eclipse の度にEclipseのクラスパスを設定し直さなければならなかったりと、チームメンバに煩わしい手順を強制する必要性は完全に排除できる。
※ この記事はあくまで技術的な方法について説明しているだけであり、ライセンス上の問題として、3rdパーティJARをSubversionなどで構成管理してチームで共有してもいいかどうかについては、各自で確認してもらいたい。
Mavenの最大の利点の1つに、依存JARライブラリがローカルPC上の中央リポジトリで管理され、プロジェクト毎の管理が必要ないという特徴がある。しかし、利用したいライブラリがオープンソース︵OSS︶でなかったり、OSSでも非常にマイナーなものだったりすると、リモートリポジトリに無くて使えない。 この場合によく説明されるのが、以下のようにしてJARをローカルリポジトリに手動でインストールする方法だが、チームで開発しているときに、この作業をメンバひとりひとりにやらせるのは非常に格好が悪い。
> mvn install:install-file -Dfile=<JARへのパス> ...かといって、Antの時代に戻ってプロジェクトの lib フォルダの下にJARを直接置くとすると、今度はIDE︵たぶんEclipse？︶のクラスパス設定︵.classpathなど︶もSubversionで構成管理しなければならない上、mvn eclipse:eclipse を実行したときはクラスパス設定はクリアされてしまうので、その度にまたIDE上でクラスパス設定をしなければならない。めんどうくさい・・・
以下2つのいずれかの方法を採用すれば、もっとスマートに3rdパーティJARを扱うことができる︵個人的には、2番目の方法がオススメ︶。 (1) プロジェクト内にMavenリポジトリを作る (2) system スコープと ${basedir} を使う
(1) プロジェクト内にMavenリポジトリを作る まず最初に紹介するのは、プロジェクトの中にリモートにあるのと同じMavenリポジトリを作ってしまう方法。︵ここでは、Sunが提供する activation.jar を3rdパーティJARの例として説明する︶
my-projectリポジトリのレイアウトや pom ファイルの書き方は、ローカルリポジトリなどを参考にする。m2repo フォルダおよびそれ以下のJARライブラリは、Subversionにつっこんで構成管理する。 pom.xml では、以下のようにしてこのプロジェクト内リポジトリを参照先リポジトリの1つに加える。
+-- src/
+-- m2repo/
+-- javax/activation/activation/1.1/
+-- activation-1.1.jar
+-- activation-1.1.pom
+-- pom.xml
[pom.xml]こうすることで、m2repo フォルダ以下に置かれたJARは通常のJARと同じように pom.xml の依存設定に書けるようになる。
<project>
...
<repositories>
<repository>
<id>local</id>
<url>file:m2repo</url>
</repository>
</repositories>
(2) system スコープと ${basedir} を使う もう1つの方法は、pom.xml の依存JAR設定にある system スコープと変数 ${basedir} を利用する方法。
[pom.xml]${basedir} はMavenプロジェクトのルートパスを表す変数。system スコープは本来、JREなどのシステムが元々持っているJARをMavenから参照するための仕組みで、<systemPath>でJARのパスを直接指定できる。それを悪用︵？︶して上記のように書いてしまうことで、Ant時代と同じようにプロジェクト内でJARを管理して使うことができる。 当然ながら3rdパーティJARは、プロジェクトの lib フォルダ以下に置いてSubversionにつっこむこと。
<project>
...
<dependencies>
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1</version>
<scope>system</scope>
<systemPath>${basedir}/lib/activation.jar</systemPath>
</dependency>
</dependencies>
my-project(2)は(1)の方法に比べると非常にお手軽なのだが、本来の system スコープの使い方をしていないようで、少し邪道な気配がしないでもない。
+-- src/
+-- lib/
+-- activation.jar
+-- pom.xml
(1)、(2)どちらの方法にしても、JARをSubversionにつっこんでいる点ではAnt時代と同じだが、プロジェクトの管理はMavenに一元化され、最初に mvn eclipse:eclipse をやればいいだけになる。mvn install:install-file を各自が実行しなければいけなかったり、mvn eclipse:eclipse の度にEclipseのクラスパスを設定し直さなければならなかったりと、チームメンバに煩わしい手順を強制する必要性は完全に排除できる。
※ この記事はあくまで技術的な方法について説明しているだけであり、ライセンス上の問題として、3rdパーティJARをSubversionなどで構成管理してチームで共有してもいいかどうかについては、各自で確認してもらいたい。