Mavenについて 〜 解決したかった問題とMavenができること
前回の記事では、Mavenのインストールから簡単なプログラムの実行までをやってみました。
しかしながら、触れたばかりだと「Mavenって結局なんなのか」が分かりづらかったりします。
なので、今回はMaven自体について調べつつ、その役割をまとめてみたいと思います。
Mavenが解決したかった問題 〜 simplify the build process
Maven – Welcome to Apache Maven
Apache Maven is a software project management and comprehension tool.
前回も引用しましたが、公式のドキュメントではこの一文が最初に記されています。
「Apache Mavenは、ソフトウェアプロジェクトを管理し理解可能なものにするためのツールです」という感じですが、これだけではよくわかりません。
最近、自分が技術を調べるときによく見るのが、「その技術はどういう問題を解決するために出てきたものなの？」という点です。
今回もここに沿ってMavenを理解していきたいと思います。
https://maven.apache.org/what-is-maven.html
ここのIntroductionに、登場の背景などが載っています。
曰く、build processをシンプルにしたい、という意図で始まったプロジェクトのようです。
ざっくり訳すと、
Antで管理していたけれど、ファイルの中身（つまりビルドの方法や内容）はばらばらで、必要なjarはCVSにチェックつけるような形になっていた
→ ビルドプロセスを標準化したい、プロジェクトが何で構成されているかわかりやすく定義したい、プロジェクト情報を簡単に公開したりプロジェクトの種類に依らないjarの共有方法を提供したりしたい、、、
→ Mavenという一連のプロジェクトが始まった
という感じです。
もう少し噛み砕いてみます。
「Maven以前」の問題を考えてみましょう。
Mavenのようなツールが登場するまでは、jarを取得する方法やテストの実行方法、コンパイルして成果物を動作可能なまでに整えていくステップが統一化されていなかったという問題があったと見れます。
スクリプトは秘伝のタレ化するし、新しいjarへの依存も持たせにくかったし、そもそもjarをどこからどれだけどんな順序で取得すればいいのかも、その方法は統一化されていなかったのでしょう。
特定のサイトからインストールするにしてもバージョンが異なり得るし、jarを誰かから手渡ししてもらうような必要もあったはずです。
また開発者が別のプロダクトの開発へ移行したら、それまでのビルドに関するノウハウや手順がほぼ通用しなくなる、という事態が起きていたであろうことも想像に難くありません。
同時に、（外からjarを取得してビルドするのに苦労があるということのほかに）自分たちの成果物やjarを外に提供するときの必要な情報についても、呼び出して使う側がこの有様では定義のしようがありません。
これさえあれば誰のPCからでも一発でビルドできる、しかもその方法はプロジェクト横断的に通用する。
そんなものがあればなぁ、というところからMaven爆誕です。
pomファイルを配ってmvnコマンドを叩けば、あとはよしなにやってくれる、と。しかもこの方法はプロダクトが変わっても一緒やで、と。
pomの書き方の統一や依存解決のためのjarを置く方法の統一によって、これらを実現していきます。
また拡張性が高いため、「自社では、自分のチームではこういうルールを適用したい、こういうツールやアーキテクチャに適合的なものにしたい」みたいな要望も（新規配属者であろうとmvnコマンドひとつで簡単に利用できる形で）追記できます。
Mavenのゴール 〜 comprehend the complete state of a development effort
ドキュメントに戻りましょう。
Maven’s Objectivesの項です。
Maven’s primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time.
がんばって訳すと「Mavenの第一のゴールは、開発者に対して、最短期間で「開発努力の完全な状態を理解すること」を促すということである。」というような意味になります。
では「開発努力の完全な状態を把握すること」とはなんでしょうか。
ここも自分の解釈ですが、「いまこのプロジェクトがどう構成されているか」というこれまでの積み重ねた成果物の内容を理解できることであったり、すぐさまその成果物の挙動を確認できることであったりを指していると考えています。
そして、このゴールを達成するためのサブミッションとして、次のようなものを挙げています。
- ビルドプロセスを簡素にする〜おおまかな内容をpomに書き下すのみでOK,あとはコマンド一発
- 統一化されたビルドシステムを提供する〜設定内容や共有方法のフォーマットはプロジェクト横断的に統一されます
- 質の高いプロジェクト情報を提供する〜名称、構成物、メーリングリストetc
- ベストプラクティスを用いた開発のためのガイドラインを提供する〜「テストソースは分離するけど並行的な階層で用意する」みたいなtipsの利用を可能にする
- 新しい機能への平易なマイグレーションを可能にする〜インストールしてきたものの更新も簡単！
Mavenができること
上述してきたように、もともとはビルドプロセスの簡素化から始まり、そこからさらに広い「開発」をサポートする仕組みを提供するものになってきたことがわかります。
前回の記事で、「mavenは（単なるビルドツールよりも）もっと大きな役割を包含したもの」と記したのはこの意味です。
まあ、それこそ「ビルド」をどう捉えるかで変わってくるんでしょうが。。。
「できること」はめっちゃ広範です。
プロジェクト生成、インストール、コンパイル、テスト、パッケージング、デプロイ（成果物のアップロード）、依存性の確認etc...
それぞれに役割やコマンドがあるものの、これらを統一フォーマットのファイルやリポジトリにもとづいて実行できるようにした、という点が、Mavenという企画のキモでしょう。
なお、Mavenができること、どのようにプロジェクトのライフサイクルをカバーするかについては、下記記事の図を見ると直感的に理解できます。
2. Maven 入門 | TECHSCORE(テックスコア)
キーワードとして出てきているPOMは、Project Object Modelの略称です。
「開発プロジェクト」をモデル化する一個の案です。
利用者はこの雛形に沿ってプロジェクトの情報を書くことができ、Mavenはその雛形を利用することができます。
ここから先もMavenを使っていく予定ですが、基本がわからなくなったら立ち返り、適宜更新していこうと思います。
