ある程度の規模になってくると、プロジェクトに構造と制約を持ち込んだほうが開発の効率が上がります。

Javaはクラスをまとめるための仕組みとしてパッケージを提供していますが、もう少し大きな枠組（コンポーネント単位、 サービス単位など）での構造化をしようとするとプロジェクトを分ける必要性が出てきます。

これを普通にやると分割されたプロジェクトの数だけVCSのリポジトリを用意して、pom.xmlを用意して、プロジェクト間の関係を 依存関係として記述して……というかなり複雑かつ管理が難しい方法を採ることになってしまいます。これではプロジェクトの間に 依存ライブラリの不整合が生じたり、ビルド手順が複雑化してメンテナンスが難しくなったりするでしょう。

例としてcore, batch, frontの3つにプロジェクトを分けた場合を考えましょう。ビルド手順は次のようになります。 どの順番でビルドすればよいのかをきちんと覚えておかないと、コンパイルエラーになったりひとつ古いバージョンに依存した状態で テストしてしまったりといったトラブルが予想できます。

cd go/to/workspace
svn co http://repository/project-core && cd project-core && mvn install
cd go/to/workspace
svn co http://repository/project-batch && cd project-batch && mvn install
cd go/to/workspace
svn co http://repository/project-front && cd project-front && mvn install

Mavenは モジュール という、パッケージとプロジェクトの中間の大きさを持つ構造を提供しています。 モジュールの特徴は次のとおりです。

• プロジェクトに含まれるすべてのモジュールで設定を統一できます。

  • バージョン

  • リモートリポジトリの場所

  • ライセンス

  • 利用プラグインのバージョンと設定

  • 依存ライブラリのバージョンとスコープ

  • etc.

• 関連モジュールを一度にビルドできます。

  • Mavenはモジュール間の依存関係を自動的に解析し、モジュールのビルド順を決定

  • プロジェクトに含まれるすべてのモジュールから必要なモジュールだけを取り出してビルド可能

• プラグインの適用範囲を制限できます。

  • プラグインはモジュール単位で作用するため、プロジェクトの一部分にのみ作用させられる

  • たとえば1プロジェクトからjarファイル・warファイル・earファイルを複数生成可能

  • プロジェクト全体に作用するプラグインも存在（aggregateパラメータを利用したpmd:pmdなど）

たとえば2013年9月現在、Jenkinsはcore,maven-plugin,testといった合計7つのモジュールで構成されています。