Maven は、Java プロジェクトのビルドと依存管理を行う定番ツールです。
pom.xml という XML ファイルに、依存ライブラリ・ビルド手順・プロジェクト情報をまとめて書きます。
「規約に従えば設定は要らない」という思想
Maven は、ソースは src/main/java、テストは src/test/java、といったディレクトリ構成を前提にしています。この規約に乗っている限り、ビルド手順を書く必要はありません。
そしてライフサイクルが固定されています。mvn package と打てば、compile → test → package の順に必ず実行されます。「どのプロジェクトでも同じコマンドで同じことが起きる」ことが Maven の価値です。
Gradle との違い
| Maven | Gradle | |
|---|---|---|
| 記述 | XML（宣言的） | Kotlin / Groovy（プログラムを書ける） |
| 柔軟性 | 低い（規約から外れにくい） | 高い（何でもできる） |
| ビルド速度 | 素直だが遅くなりやすい | キャッシュと差分ビルドで速い |
| 読みやすさ | 誰が読んでも同じに読める | 書き方次第で難読化する |
選択の軸は速度ではなく「柔軟性が必要か」です。長期保守の業務システムで、担当者が入れ替わりながら10年動かすなら、Maven の「変なことができない」性質はそのまま利点になります。
依存の落とし穴
Maven はライブラリの依存を再帰的に取り込みます（推移的依存）。このため、直接指定していないライブラリが勝手に入り、しかも別ライブラリと版がぶつかることが起きます。
mvn dependency:tree で依存の木を出せます。「なぜこのライブラリが入っているのか」「どの版が採用されたのか」が分からなくなったら、まずこれを見てください。バージョンを揃えたい場合は dependencyManagement で固定します。
実務で見るポイント
- ローカルにキャッシュされる（
~/.m2）。「手元では動くのに CI で落ちる」ときはここを疑う - 社内リポジトリ（Nexus など）を挟む構成が企業では一般的
- Spring Boot は Maven / Gradle どちらでも使える。既存資産に合わせて選ぶ
同じライブラリの別の版がぶつかったときに、Maven と Gradle で選ばれる版が変わることは MavenとGradleの違いは？ で実際に試しています。