本連載の目的

本連載では、Apache Software Foundationで開発されているMaven [1] というツールを利用し、プロジェクトをいかにドライブしていくかを、皆さんに御紹介していきます。『プロジェクトのドライブ』という言葉は若干抽象的ですが、本連載の具体的な目的は以下の内容です。

1. プロジェクトの情報の明確化
2. プロジェクトの成果物生成支援
3. プロジェクトの管理支援

連載は数回を予定していますが、Mavenのバージョンアップや新機能の追加などに応じて変更できればと考えています。

ありがちな問題

さて、皆さんは、今までいくつものシステム開発のプロジェクトを経験してきたと思います。 その中でこんな問題に直面したことはありませんか？

• 開発環境を構築するだけで丸一日かかってしまった(時間の無駄無駄ァ)
• 一介のプログラマなのでプロジェクト全体の規模が見えない(今全体のどの辺りなんだろう？)
• 途中参加のプロジェクトで文書も情報もなくて途方に暮れてしまった(結局ソース見るんだけど...)
• 誰がいつ何を作っているのか、よくわからない(管理者は知ってる？)
• Antでいろいろなタスクを使おうと思ったけど、面倒でやめてしまった(XML長げーよ！)
• プロジェクト始まる度に毎回毎回同じようなツール準備してるような...(しかも面倒)
• etc...

実は、上記は筆者の体験でもあります。多かれ少なかれ、皆さんも似たような経験をされているのではないでしょうか。いずれの問題も、その時は困りますが、とりあえずなんとかなってしまうため「仕方ない、そんなもんだ」と考えてしまってはいませんか？ 筆者も以前はそうでした。

そこでMaven

Maven [2] はJakarta ProjectのTurbineプロジェクトの成果物として開発されました。現在はAnt [3] と同様に、Jakartaの冠をとって、Apache Software Foudation直轄のプロダクトとして開発されています。Mavenとは「専門家、達人 [4] 」という意味です。

Mavenは、不明瞭なソフトウェア開発プロジェクト、という存在をモデル化しました。そのモデルがPOM(Project Object Model)です。Mavenの考えるソフトウェアプロジェクトとは、大まかに次のような構造になっています。(U言語 [5] ライクに表記してみました。) このモデルを見ればおわかりになると思いますが、Mavenの「プロジェクト」の定義は、プロジェクトが実施されている組織、ソースリポジトリ、メーリングリスト、開発者、貢献者、ライセンス、依存ライブラリ、成果物の構築、各種レポートから構成されます。POMはproject.xmlというXMLファイルに内容を記述することになっており、project.xmlは継承して再利用することも可能です。Mavenはこのモデルを元に、プロジェクトに対して様々な働きかけを行います。

=====================
    Project
---------------------
id String
name String
organization Organization
package String
description String
repository Repository
mailingLists           <>----> MailingList
developers             <>----> Developer 
contributors           <>----> Contributor
licenses               <>----> License
dependencies           <>----> Dependency
build Build            
reports                <>----> Report
properties             <>----> any element
=====================

Mavenの生い立ちからもわかるように、POMはオープンソースプロジェクトを意識したモデルになっています。そのため、実際のシステム開発におけるプロジェクトの全情報がPOMに定義されているかというと、残念ながらそうではありません。Mavenはプロジェクトにとっての、万能薬にはなりませんが、問題を浮き上がらせる試験薬、あるいは問題の防止をする予防薬としては十二分な力を秘めています。

また、Mavenの定義するプロジェクトは１つのJarファイルを最終的に生成する規模を想定しています。「Jar１つで収まる規模のプロジェクトなんてそうそうあるはずがないじゃないか！」なんて感じた方いますか？その通りです。複数のJarファイルを生成するような規模は、プロジェクトを分割し、サブプロジェクトの集合として構成すべきなのです。Mavenでは複数のプロジェクトを管理するための機能も備えています。複数のプロジェクトの管理方法については、以降の連載で解説する予定です。

Mavenの主な機能

一番抽象的なPOMの話が済みましたので、次はもっと具体的な話、つまり「Mavenで何ができるのか？」について紹介します。Mavenには様々な機能がありますが、ここではMavenを３つの側面からみた機能について紹介します。

ビルドツールとして

Mavenはビルドツールという側面をもっています。これは同じApacheプロジェクトであるAntがよりユーザフレンドリーになったツールであると考えてもらってよいでしょう。それもそのはず、Mavenは内部でAntを使用しており、Antで使用できる全ての組込ターゲットを直接使用できます。

さらにAntでは、拡張タスクとして提供されていた様々な機能を、Mavenではプラグインという形で利用することができます。プラグインを利用する際には、プロパティファイルを設定するだけでよく、専用のXMLの記述は必要ありません。またプラグイン自体もコマンド１つでインストールすることができます。

この際、プラグインがインストールされていれば、build.xmlに記述していたようなタスク毎の設定は必要ありません。必要なのはプロジェクト毎に異なる項目をproject.propertiesファイルに設定するだけです。

Mavenのプラグインは、JellyというXMLのテンプレート言語を使ってAntのターゲットを使用するのに必要なXMLを記述しています。プロパティファイルに設定したプロジェクト固有の値を動的にXMLに埋め込んでAntを実行させることで、利用者が余計なXMLを記述せずとも、拡張タスクの恩恵を受けることができるようになっています。

プロジェクトサイトジェネレータとして

Mavenはプロジェクトサイトジェネレータという側面をもっています。MavenはPOMに定義されている情報にアクセスして、HTMLとしてプロジェクトサイトを生成することができます。生成されるHTMLにはPOMに直接記述している情報のほか、ソースコードを利用して生成できるJavadoc、テストレポート、クロスリファレンス、スタイルチェッカ、クラスの依存関係、リポジトリに関するCVS履歴、ChangeLog、などなど、様々な情報が含まれます。これらのレポートもAntで使用するようなXMLの記述なしに、プロパティファイルの設定だけで生成することができます。

ライブラリ自動インストーラとして

Mavenはライブラリ自動インストーラという側面をもっています。MavenはPOMのdependenciesで定義している依存関係のあるartifact(成果物、つまりライブラリ)をリモートリポジトリより自動取得して、ローカルリポジトリにインストールする機能があります。

オープンソースで開発されているライブラリの他、独自のプロジェクトで開発、使用しているライブラリも、自前のリポジトリを設定することで、同じ様に自動でインストールすることができます。この機能のおかげで、プロジェクト毎にライブラリを自前でインストールしたり、ライブラリ自体をCVSに格納せずともライブラリが利用できます。

今回のまとめと次回予告

今回はMavenの概要として、POMと実現可能な機能について触れました。次回はMavenの実際の導入について触れる予定です。