Maven

やっとなんとなく判ってきた．そろそろ入門書を買ってきても役に立つような気がする．
このツールのキモは，リポジトリの整備/管理と再利用にあるのだろう．最初に面食らうのがMaven独自のプロセス観なので，そちら側に目が行きがちだけれども，それが提供する生産性は大したことはないと思う．

実例

試しに，archive.eclipse.org にあるファイルのうち，PizzaFactory3 のビルドに必須のいくつかを，独自のリモートリポジトリに突っ込んでみた．リポジトリは普通のWebサーバがあれば構築できる．デプロイを考えるとWebDAVだと楽そうだけれど，他のファイルアップロード手段も提供されている．
PF3 Express edition の pom.xml に，それらのアーカイブとの依存性を記述する．
次に，依存性を示したファイルをどの時点でどこに展開するかを示す．これも pom.xml の中に書く．

最後に，mvn install などする．ビルドに必要な Eclipseのアーカイブは，他のMaven用プラグインと同様に，手元に無ければリモートリポジトリから引っ張ってくる．これがantの世界(PDEの標準世界)であれば，getしてunzipして…と事細かに指示しなければならない．ファイルは複数になり，ビルドファイル自身の見通しも悪くなる．

pde-maven-pluginの出来が今ひとつ良く無いので，build.propertiesファイルが別途必要となる．しかしその気になれば(pde-maven-pluginをhackすれば)，pom.xml ファイル一本で，RCPアプリケーションの作成まで行けるだろう．

svnなど他の構成管理ツールとmvnリポジトリの使い分け

svnには，タグを打ってもその後変更可能という，(構成管理上は)恐ろしい穴がある．リビジョンで指定すれば良いのだけれど，何となく怖い．
一方，mvnリポジトリには，パッチに類する概念が無さそうである．細かい変更であっても，全体が保存される．

だから，mvnリポジトリは，誰が見ても凍結状態にあるソースファイル群や，jar/zip/tgz/libなどで固められリリースされたコンテンツ類の格納が向く．大規模チームなら，リリース責任者が使い育てるべきものだろう．
一方，svn は，プログラマやコンテンツ作成者向け．日々変更が加えられるファイル群の管理に向く．
一人プロジェクトでは，2つのリポジトリを使い分けることで，自分が今何をしているのかが明確になるというメリットもあるかもしれない．

感想

必要なものを勝手に集めてきてビルドというのは，ちょっとでも腕があるビルド担当者なら，独自のノウハウがいくつかあるものだと思う．Mavenは，それを標準化してしまうという点で，単なるビルドツールを超えた構成管理ツールなのだなぁと思った．もっと早いうちから使っていればよかったと反省．独自のビルドスクリプトは，手順書を用意しないと他の人が使えないとか，案外コスト高いし．

たぶんこの先は…

セマンティックウェブな要素が入って，依存関係がありそうなファイルをクロールして「もしかして:」と表示したりするのかもしれないなぁ．