Maven 2をキャッチアップする

作者 James Kao , 翻訳者 松本 清一 投稿日 2007年9月2日

セクション

運用/インフラ,

プロセス/プラクティス,

デベロップメント

トピック

Java EE ,

Maven ,

Java ,

言語 ,

Japanese Build systems ,

プログラミング ,

Ant

共有 |

Mavenは、JavaやJ2EEプロジェクトに対するパターンベースのビルドフレームワークである。任意のプロジェクトに対してビルドスクリプトを作成できるだけでなく、J2EE、Struts、Hibernate等にも対応している。さらに、プロジェクトの開始から、テスト、パッケージング、デプロイに至るまでの構造や構成について、予め決められた形がある。Mavenの本(Better Builds With Maven)の著者は、次のように言っている。

Mavenには、ビルドの標準セットや、アーティファクトリポジトリモデル、プロジェクトを記述、管理するソフトウェアエンジンが含まれています。Mavenは、ビルド、テスト、プロジェクトのデプロイに対する、標準的なライフサイクルが決められています。また、Maven標準に則ったプロジェクトであれば、一般的なビルドロジックの再利用が簡単にできます。Apache Software FoundationのMavenプロジェクトは、プロジェクトオブジェクトモデル(POM)で書かれたものを解釈するソフトウェアツールを作っている、オープンソースのコミュニティです。

Mavenは、依存関係をサポートするために、関連するファイル全てを管理しているibiblioと提携している。ibiblioには、有名なリポジトリのよく知られたファイル全てを、デフォルトで管理している。(ビルド中心であることを除けば、Gemのメカニズムを思い出させる)このような、まるで魔法のような機能が組み込まれていることにより、Mavenベースのプロジェクトは、だまされたかのように簡単に始められるのに、いつのまにか292ページあるMavenの本の内容を理解したかのようになる。その意欲的な活動範囲を考えれば、Mavenは、これまでにとても強力な印象を与えるべく、Maven開発チームは対処している。

Mavenのベストプラクティスは、多くの場合、企業の実社会での問題を解決しません。私がそれに対処するときでさえ、今ある企業のプラクティスや現在のツールセットで、固有の問題に対処します。

先日、Matt Raible氏は、AppFuseをAntからMavenに移行したことについて、報告している。

Mavenに移行したことについての最も興味深いことの一つとして、簡単にAppFuseを作ることが出来るMavenは、プロジェクトのスタートキットというよりはむしろ、フレームワークのようです。私たちは、特にAppFuseを最新版にアップグレード可能な人にとっては、ほとんどの人たちがそれを望んでいると思っています。これらを希望する人がいる一方で、アップグレードにうんざりするようなフルソースバージョンを好む人もいると思いますが、私はそれに関してとやかく言いません。

もちろん、Mavenに移行する本当のメリットは、他にもあります。ここ何ヶ月かの間、メーリングリストがとても盛り上がっています。不意にツールが現れたことで、私は、トレーニングに関する問い合わせを沢山うけました(私は、Spring、Hibernate、Ajax、Maven、AppFuseの3日間コースを担当しています)。私にとっては、AppFuse1.xよりも2.xの方が複雑に見えますが、コミュニティは、そう感じていないようです。AppFuseプロジェクトで活発に活動する開発者の数が増加していることから判断すると、開発者は、Mavenベースのシステムにも興味を持っているようです。そしてまた、私たちもMavenで仕事をしています！

Maven 2がリリースされてから、アップデートは継続的に行われ(最近、2.0.6がリリースされている。バグFIXや、コアエンジンの有用性の為にインクリメンタルな改善をおこなっている。リポジトリも頻繁にアップデートされ、SpringやTomcatのような一般的なものから、openid4javaやmuleのような一般的でないものにおいても、大部分が最新版をサポートしている。今年の初め、リードコミッタであるJason Van Zyl氏とJohn Casey氏が、Mergereから離れてMaven2のリーディングスポンサーと宣伝担当になった。しかし、開発の方にも積極的に参加し続ける。

（原文は2007年4月17日にリリースされた記事です）