Mavenの特徴 - いつかMavenと呼ばれたい@Wiki

Mavenの特徴

Antの出現は、各人各様に行われてきたビルドプロセスの自動化に、一つの標準化をもたらしてくれました。
しかしプロジェクトの巨大化に伴って、そのビルドファイル(build.xml)に記述される処理の量も巨大化していきました。今やbuild.xml自体、一つの巨大なプログラムであり、そのメンテナンスの負荷は決して小さいものとは言えません。
ま た依存するライブラリやリソースなどの外部環境も複雑になり、プロジェクト内のディレクトリ構成とその役割もプロジェクト毎にまちまちです。ある環境で正 常に動いていたプロジェクトでも、別の環境でビルドを成功させるには大きな手間がかかることもしばしばです。本来どこでも簡単にビルドできるというプロ ジェクトの可搬性も失われてきました。

Mavenはこういった問題を解決するために新たに出てきたプロジェクト管理ツールです。
Apache Mavenプロジェクトのサイトに掲げられたMavenの目標は以下の通りです。

• Making the build process easy
• • ビルドプロセスを簡単に
• Providing a uniform build system
• • 標準ビルドシステムの提供
    
• Providing guidelines for best practices development
• • 開発ベストプラクティスのガイドラインの提供
• Providing quality project information
• • 価値あるプロジェクト情報の提供
• Allowing transparent migration to new features
• • 最新機能への移行が容易
    

これらの目標がどのように実現されているのか見てみましょう。

・Making the build process easy：ビルドプロセスを簡単に

・Providing a uniform build system：標準ビルドシステムの提供

・Providing guidelines for best practices development：開発ベストプラクティスのガイドラインの提供

Mavenのビルドファイル(pom.xml：POMはProject Object Modelの略。Maven1ではproject.xmlというファイルでした。)を見て最初に驚くのは、そのシンプルさです。
プロジェクトの名前やプロジェクト内容の説明、そしてプロジェクトに参加している開発者の一覧・・・といったプロジェクトの静的な情報がその中心です。何をどのようにビルドするのか・・・といったビルドプロセス(ターゲット)の記述が見当たりません。
Mavenでは、どのようにビルドするのか(Goal:ゴール)、というビルドプロセス(Build Lifecycle:ビルド・ライフサイクル)が、そのビルド成果物(Artifact:アーティファクト)の種類毎に用意されています。
この標準に従う限り、ビルドファイルに複雑なビルド処理を記述する必要がないのです。
またMavenは依存するライブラリ（Dependencies）を自動的にダウンロードしてクラスパスにセットします。ビルドの際に、もうクラスパスのことで悩む必要はないのです。

このように、あらかじめ用意されているビルド・ライフサイクルやゴール(プラグインとして用意されています)を利用し、標準ディレクトリ構成に従う限り、可搬性の高いビルド環境を簡単に構築できてしまいます。
中には標準に従うということに抵抗を感じる方もいらっしゃるかもしれません。でもこれらの標準やプラグインは、多くの開発者の経験から出てきたベストプラクティスを具現化したものです。
Ant で開発を行う場合も、毎回スクラッチビルドでビルドファイルを書くのではなくて、過去の成功プロジェクトのbuild.xmlをテンプレートにして書くこ とが多いのではないでしょうか。Mavenは書かずに利用できるテンプレートとして、プラグインや標準ルールを用意しているのだといえます。プラグインと 標準ルールを通じて先人の知恵を伝授する・・・ここがMaven(＝達人)と呼ばれる所以なのでしょうか。
チームのベストプラクティスをプラグイン化することによって、個人の知識の範囲にとどまっていたものをチーム全体で共有し、プロジェクトの品質を向上させることもできます。

Providing quality project information：価値あるプロジェクト情報の提供

Mavenはプロジェクト管理ツールだと言われます。でも、たとえばMS-Projectのような進捗管理をするツールではありません。
Mavenはプロジェクトのコンテンツについて、さまざまな情報を視覚化してWEBサイトとして公開することができます。
た とえばビルド成果物の品質について、Checkstyleなどによる自動コードインスペクションや各種テストをビルド・ライフサイクルの中で実行し、その 結果をWEBサイト情報として出力します。最近のソースコード更新頻度を開発者別、ファイル別に集計したりもできます。
これらの情報は、ビルド成果物そのものが語るプロジェクト状況として、プロジェクトリーダーの方はもとより、開発者自身にも有益な情報になるのではないでしょうか。
その他、プロジェクト内容説明、現在のバージョン、開発者一覧、構成管理されているロケーション・・・といったプロジェクトの素性を表す情報も出力します。うまく利用すれば、システム資産管理にも使えそうです。

この機能は、開発者のみならず、プロジェクト管理者やライブラリアンといったさまざまなロールの人たちにも恩恵をもたらす、とても魅力的なものです。
ただし残念なのは、Maven2の国際化対応が不十分なため、日本語での情報出力に大きな制限があることです。(Maven1ではうまく動いていたのに・・・)
Apache Mavenプロジェクトでも既に課題として認識されていますので、近い将来解決されるのではないかと思われます。

Allowing transparent migration to new features：最新機能への移行が容易

Mavenは、使用しているプラグインとその関連するライブラリが更新された場合、自動的に開発環境にダウンロードして更新することができます。
もちろん、開発者が自動更新を制御して、利用するバージョンを決めることもできます。
(プラグインの自動更新機能はMaven2より実現されたものです。Maven1ではMavenの利用者が意識してプラグインのバージョンアップを行う必要がありました。)

もう一つのMavenの魅力と可能性

ApacheMavenプロジェクトの掲げる目標を基にしてMavenはどういったツールなのか見てきました。
実はもう一つ、個人的にMavenに強く惹かれる理由があります。
Mavenは開発者のみならず、プロジェクトに参加するさまざまなロールの人にとっても有効なツールとなるのではないかということです。

• 開発者

Mavenプロジェクトは、たとえばEclipseといった統合開発環境に簡単にインポートできますので、お気に入りの開発環境でそのまま開発を行うことができます。

• テスト担当者

Mavenはさまざまなテストフレームワークと連携して、簡単に自動テストを構築できます。

• プロジェクト管理者

Mavenは開発成果物からさまざまなレポートを作成できます。開発者からの進捗報告とは異なるプロジェクト状況を知る情報を得ることができるでしょう。

• システム運用担当者（デプロイ担当者）

Mavenプロジェクトはどのような環境でも、簡単にビルドができます。環境の違いによるビルドのわずらわしさにとらわれることなく、デプロイ作業に専念できます。

• ライブラリアン

Mavenは各プロジェクトが利用するライブラリのバージョンをコントロールできます。組織全体、あるいは多くのサブプロジェクトからなる巨大プロジェクトのライブラリの管理が可能になります。

それぞれロールの異なる複数のアクターが同じMavenというツールを使うことによって、異なる自分のユースケースを満足する・・・少し欲張りすぎでしょうか?
もちろんMavenだけで何から何までできるわけではないでしょうし、まだまだ経験不足で、これを実現するためのプラグインも十分ではありません。
でもMavenを通じて各ロールの仕事がもっとつながりを持って協調していかないか・・・Mavenは、そんな期待を抱かせるツールなのです。