Maven2 を利用する側が知っていないといけないこと

make 使ってビルドする人が makefile の書き方を知っている必要がないように、ant を使ってビルドする人が、build.xml の書き方を知っている必要が無いように、Maven2 を利用する人は pom.xml の書き方を知っている必要は無い。*1


では、何を知っていないといけないのか?ということを考えてみた。ちなみに、社内で使う場合を前提としている。あしからず。

Maven2 とは何か?ということ

ant の代わりくらいに思ってもらえば十分だと思うがそれだけだとメリットが分からないと思うので、何かしらの説明は必要だろう。

\¬ŠÇ—@ŽÀ‘H“ü–å@‘æ4Í Maven2‚É‚æ‚éƒrƒ‹ƒh“ü–å@‚È‚ºMaven2‚È‚Ì‚©H

一番エッセンスがまとまっていると私が思ったのが上記のページ

  • プロジェクトのディレクトリ構成が統一される
  • 統一されたビルド方法で war、jar が作れる
  • ライブラリの依存関係が解決される。

上記が Maven のメリットのまとめだと思う。ライブラリの依存関係の解決に関しては、依存関係の定義をあらかじめしておくと、利用時は、Maven が定義を見て勝手に依存関係を解決してくれるということ。*2

リポジトリの概念

オープンソースで公開された jar は「セントラルリポジトリ」と呼ばれる場所に公開されている。自分たちの成果物は誰でも見れるセントラルリポジトリに置くわけにはいかないので、「セントラルリポジトリは読み込み専用だ。


Maven ではローカルリポジトリというものがあり、各個人の環境にその人専用のリポジトリが持てる。利用側の人がこれを使うことは無いと思われる*3ので、意識する必要はない。


重要なのは、社内リポジトリ。自分たちの成果物をここに入れることで、社内の他の人とそのモジュールを共有することができる。つまり、社内リポジトリは読み込み、書き込み、両方がありえる。



長々と書いたが、理解しておかないといけないのは、作ったものを社内の同僚に使ってもらうためには、この「社内リポジトリ」にファイルを置く必要がある、ということだけ。

Meven2 のインストールの方法

Linuxディストリビューションであれば、大体どれも、apt-get かそれに類するコマンド一発で入るが、Windows は若干煩雑。
http://d.hatena.ne.jp/arfyasu/20081122/1227304110
ちょっと見た中で上記が一番簡潔。

m2Eclipse-light のインストール

開発は Eclipse を使って行うと思うので、Eclipse 上に何かプラグインが必要。私が使わせてもらっているのは、m2Eclipse-light。
m2eclipse-lightプラグイン - Skirnirnismal

Eclipse のアドオンの更新メニューから、サイトの追加を選択し、

http://eclipse.seasar.org/updates/3.3/

を入力し、インストールするだけ。

setting.xml の配備

そして、もっとも大切と私が勝手に思っている、setting.xml。これが適切に設定されてないと、まともに動いてくれない。*4同じ社内であればこれの内容は普通は共通になるので、環境に合う setting.xml を管理者が用意し、使う側はそれをホームディレクトリの .m2 ディレクトリに置く必要がある。

社内リポジトリへのモジュールのデプロイ方法

作ったもの(jar や war)を社内で共有するために行う。これをしないと、Mavenリポジトリからしかモジュールを取得できないのだ。方法は非常に簡単。

% maven clean deploy

clean はゴミが気になる場合は入れる。別に入れっぱなしで問題ないと思う。

パッケージの作り方。

アプリケーションサーバにデプロイしたい場合は、war ファイルが欲しい。war ファイルを生成する方法は、

% maven clean package

target ディレクトリに war とか jar が出来ているはずだ。

以上かな?

おそらく使う側として知っていないといけないのはこれだけじゃないかと思う。依存関係がどうとか、バージョンがどうとか、というのは、管理側が気にすることになってくると思われる。*5


maven 難しい、こんな難しいもの何で入れるの、ant でいいじゃんという声もあるのだが、確かにリポジトリの用意とか面倒だし、依存関係の設定はほぼ設計レベルの作業になることが多い。管理者がその辺をやっちゃえば、後の人は楽できるという仕組みだと考えて使えばいいのじゃないかなーと個人的には思う。


つまり、プロジェクトの修正担当するだけの人とか、機能追加するだけの人に、pom.xml を作らせようとはしないであげて・・・ということが言いたい今日この頃。

*1:ここで言ってる「使う人」「利用する側」というのは、共通フレームワークを使って構築された各サービスの機能拡張をしたり、バグ修正をしたりする人を想定している。新規サービスを新たに作る人にはまた別の知識が必要だろう。

*2:別に Maven人工知能的に勝手によきにはからってくれるわけではないが、使う人から見たら Maven が勝手にやってくれてるように見える

*3:Maven は勝手に使っているが、利用側の人が意識してこれを使うことは無い、という意味。使う人が意識してローカルリポジトリを使うケースというのは社内リポジトリが無い場合だと思われるが、お試しで Maven 使ってみるという場合以外は社内リポジトリが存在するだろう。

*4:社内リポジトリの設定および、大抵の場合、proxy の設定が必要になってくる

*5:作ったものを公開するときにバージョン上げなくていいの?という話はあるかもしれないが、基本的には開発に入る前に、バージョンを SNAPSHOT にしておき、使う側の人はバージョンを一切いじらずに、上書き上書きでリポジトリに入れてもらえば問題無いと思う。リリース時に管理者がバージョンを付ければいい。