議論：Mavenはビルドに適したツールか？

作者 Ryan Slobojan , 翻訳者 白石 俊平 投稿日 2008年2月12日

セクション

運用/インフラ,

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

デベロップメント

トピック

Grails ,

Groovy ,

Java ,

Maven ,

Artifacts & Tools ,

動的言語 ,

Buildr ,

言語 ,

Japanese Build systems ,

プログラミング ,

Agile ,

Ant ,

Debate

共有 |

最近、Maven(サイト・英語)の実用性についてたくさんの論議がなされている。MavenとはJavaベースの依存性管理ツールのことで、多くのプロジェクトで利用されている。InfoQは、問題の争点が何であるか、またどういった結果をもたらすのかを理解するために、この議論をより詳しく調査した。

Apache Tapestry(サイト・英語)とApache HiveMind(サイト・英語)の生みの親であるHoward Lewis Ship(source)は最近、彼の携わっているプロジェクトがMavenを使っていて遭遇した、いくつかの問題についてブログエントリを投稿した(source)。

EclipseとIDEAの双方において、Mavenは非常に遅く、バグが多く、そのうえ不安定でした。IDEA７は同期が明示的に行われるので、Eclipse（とMavenプラグイン0.0.12）よりは多少ましです。それでもやはり物事をうまく運ぶためには、果てしない量の調整とフィックス、そして祈りが必要だと思われます。
本質的にはMavenは偉大なアイデア（依存性管理については非常によく考えられています）ですが、ビルドの実行については、不快と言えるほど悪いプラグインシステムの上に成り立っています。その不快な部分というのは、何か新しい壊れたプラグインが中央のMavenリポジトリにリリースされたおかげで、月曜に成功していたビルドが火曜には失敗するかもしれない、と言うことです。

Shipは、Mavenを理解して利用するための大きな障害はドキュメントの不足にもあると述べ、依存性管理システムの代用品としてIvy(source)を推奨した。Eugene Kuleshov(source) はMavenのpom.xml内にプラグインのバージョン番号を記すことが、プラグインの問題解決になるだろうと指摘した(source)。またCharles Miller(source)はそれに答え(source)、そうしたアドバイスがMavenユーザガイドやセットアップガイドのどこにも無い、としている。

Don Brown(source)も最近、Maven 2に見られるいくつかの問題 - HTTP接続のプーリングや、並列アーティファクトダウンロードを含む - を解決する、彼が作ったMavenの新しいビルドについて投稿している(source)。Mavenのこのブランチは作業中(source)で、この変更がトランクに(source)統合される望みがある。

この議論に加わっている人は他にもいる。Jonas Fagundes(source)は、「なぜGrailsはMavenを使わないのか」(source)という質問を投げかけると同時に、こんなコメントをしている。

Maven は素晴らしいツールであり、あらゆる言語に存在してほしいと我々が望むタイプのツールです。これはモジュール化されたプロジェクトのビルドツールなのです。依存関係、ビルドサイクル、テスト、パッケージング、そしてあなたの作成したアーティファクトをリポジトリにて公開することが可能です。これはプロジェクトをビルドするためのツールであり、標準的なビルドツールより一歩進んでいます（現に、最初のバージョンはAntの上に構築されていました）。プロジェクトに対してデフォルトのディレクトリレイアウト - 非常によいデフォルトです- を提供しており、プロジェクトを開始するのに必要なのはプロジェクトの名前を選ぶことだけで、デフォルトのパッケージが生成されます。何も手を加えずとも全てはうまく動作しますし、もし何かを変えたければ、Mavenリポジトリで管理されるであろう新しいプラグインを提供したりして、コンフィグレーションを行うこともできます（そのプラグインは、単にある種の依存性であり、POMの設定語に自動的にダウンロードされます）。railsコミュニティによって考え出された「Convention over Configuration」（設定よりも規約）を大々的に採用しています。

Fagundes氏の「なぜGrailsはMavenを使わないのか」という質問に対して、G2One(サイト・英語)のCTOであるGraeme Rocher氏(source)は「Grailsの主な狙いはJavaEEの簡素化である」と回答している(source)。

今のところ、Mavenはこれに完全に逆流しています。なぜプロジェクトを作りたいときに、いつもマニュアルを読まなきゃならないのでしょう？つまり、私はそうした全てのたわごとを覚えているすべを持たないし、取りかかろうとしてもドキュメントがあまりに酷い、ということです。
私は、Mavenのように複雑なビルドシステムの受け入れに前向きなのはJavaユーザだけだと思っています。その他のコミュニティにとっては、"これはなんの地獄だ？"と言うことになるでしょう。私にとってのMavenは、ビルドシステムにおけるEJB2です。：複雑すぎて、技術的すぎて、知識を要しすぎます。コードを生成してくれるIDEだけが、Mavenとうまくやれるでしょう。

Matt Raible 氏(source)はRocher氏の記事に加えて(source)、２つの大きな問題点と、それらの潜在的な解決策を示唆した・

1. 中央レポジトリにおけるお粗末なメタデータ - もし利用者のフィードバックに基づいて依存性が決められていたら、レポジトリメタデータはもっときれいなものになるだろう 
2. プロジェクトメタデータの情報源としてのPOM.xml - pom.xmlが必要とするXMLとその冗長性は、ビルド情報の解析を難しくしている。Groovyなどの他のフォーマットでプロジェクトのメタデータを記述できれば、これは簡単になる
   

加えて、Raible氏はこう言っている。

私はまだMavenのファンです。その主な理由としては、AppFuseの管理とリリースが非常に簡易化されているからです。私が将来GWTやSeam、Grailsの開発を行うときには、Mavenを開発に使おうとトライするのは間違いありません。なぜかというと、私は使い方を学んできたし、他の人が言っているような苦痛を感じていないからです。Mavenは本当に大きなプロジェクト（例えば、３０個以上のWARファイルを生成するような場合）でこそ真の力を発するのだとも思っています。本当に大きなプロジェクトにおける Antベースのシステムは、非常に大きな負担となり、保守も難しくなる可能性があります。それだけではなく、（単独のWARをビルド／テスト／デプロイするという環境で）モジュール化されたビルドシステムをAntで維持することはとても困難です。私の経験上、個々が依存関係で結ばれたMavenベースを最新に保つのに比べ、本当に巨大なAntベースのシステムで、全てを最新に保とうとするのは非常に時間がかかります。きっと、Antで全てのテストプロセスを実行するのに５分待つよりは、サブプロジェクトで”mvn install”コマンドを実行するほうがよりスマートでしょう。

いくつか、他からも引用すると、

• boomtown15(source) -- 私は、Mavenを簡単に見限る人たちのことが信じられません。実際、慣習さえ理解してしまえば、単純なものなのです。初めてのプロジェクトをセットアップするのはそんなに楽ではないし、習得するにはちょっと難しいのも分かります。しかし私はそれ以上のメリットがあると信じているのです。
• Xavier Hanin(source) -- 私がMaven支持者であるかというと、どちらとも言えません。非常にさっぱりとした標準的な方法でプロジェクトをビルドする事が出来る、といった Mavenの考え方は好きです。何が嫌いかというと、ドキュメントや柔軟性・堅牢性の欠如、そしてあまりに黒魔術的である、という事です。
• Les(source) -- ...Mavenに対する逆風は、私にとって驚きの連続です。Mavenは、初めのうちは習得するのが非常に難しいですが、その見返りとして、より物事が複雑になればなるほど、より物事を単純化してくれます。 
• Tech Per(source) -- Mavenが複雑で、技術的すぎ、良いドキュメントが不足している、等の意見に賛成はしますが、それでもまだMavenが一番良いと感じています。私は Mavenを連日使っていて、もちろん不平だらけです。しかし（私が熟知している）Antに戻ろうともしたのですが...それも苦痛でした。その結果、私はMavenからどれだけのものを得ていたかを知ったのです。
• Ortwin(source) -- 我々は今のところ大事な事柄にはAntを使っています。なぜなら、Mavenによるビルドを保守するには、非常にたくさんの時間と知識が必要だからです。 Antでのビルドが非常に単純、と言うわけではありませんが、少なくとも全ての時間が割かれることはないからです。次はBashスクリプトを用いるつもりです。XMLによるプログラミングというのは、単に不快なだけです。
• Steve(source) -- NetBeansのMavenサポートは、私が今まで見てきた他のIDEのどれより優れています。ほどほどのサイズのプロジェクトには、日々それを使うと良いでしょう。Mavenは非常に多くのものをもたらしますし、私はそれを捨ててしまおうとは考えません。確かに、Mavenを飼い慣らす方法を学ぶのにはいくらかの投資が必要ですが、一度それを行ってしまえば、選択の余地は他にないと言うことがわかるでしょう。依存性管理は、予期しないものからあなた自身を守り、目的ベースのプロファイルやビルドライフサイクルステージについての理解をもたらし、あなたがリポジトリに追加するものについて「注意深く」なります。これらは全て、猛獣（Mavenのこと）を飼い慣らすための鍵となるものです。
• Kevin Menard(source) -- 私の考えでは、SNAPSHOTシステムはうまく機能していないように思えます。正しく使えば、プロジェクトをアーリーアダプターにテストしてもらうための、非常に優れた方法と成り得ます。しかし、ほとんどの場合、それは単に正式リリースを避けるための仕組みとして使われています。
• distiller(source) -- ...私はこれまでMavenの良さを説いていましたが、Ivyの支持者になりつつあります。Ivyは、リポジトリのセットアップ方法がより柔軟ですし、ビルド自体はAntに委譲するので、Mavenのようにプロジェクトの構造を決めつけようとはしません。
• Jay(source) -- [Howard Lewis Ship], あなたの批判は正しい。あなたと同じように、私もいろいろ激怒させられました - 壊れたリリースをダウンロードしたり、ドキュメントには全くの嘘が書いてあること、などなど。しかし、その代わりになるものはなんでしょう？ Convention over Configuration、依存性管理、そして多量のプラグインを使える他のツールを私にくれたら、あなたの批判について考えてもいいでしょう。今の段階では、スクラッチから始めるよりも、あなたが抱えている問題（ドキュメントの問題は特に酷いです）を解決する方にエネルギーを割いた方がいいと思います。
• Jon Scott Stevens(source) -- ...これは覚えておいてください... 我々は、多くのJava開発者にインタビューしてきました。そして、我々がインタビューした誰一人として、mavenの事を本当に素晴らしいという人はいませんでした。
• Peter Backlund(source) -- Mavenは非常に便利なツールで、多くのプロジェクトで私の役に立ってくれています。あなたはMavenの哲学に沿う必要があります。さもないと、おそらく酷い目に遭うでしょう。もしあなたが"これがプロジェクトを組織化するオレ流の方法で、Mavenをそれに従わせるんだ！"という態度をとるなら、あなたの世界は苦痛に満ち満ちることでしょう。もし代わりに、あなたがMavenに従って作業するなら、多くの良いものがただで手にはいることでしょう。
• Matt Raible(source) -- 私は、誰もがMavenを悪いアイデアだと考えているわけではないと思います - それは単に、良いアイデアに対する貧弱な実装なのです。
• Rick Hightower(source) -- 日々私はMavenを呪っています。そして、日々私はMavenを賞賛しています。私は常に、それを酷く嫌っていますし、愛してもいます。しかし私は、 Antを使うのに比べたら雲泥の差で素晴らしいと思っています。私は多くの旅をし、多くのコンサルティング/開発をしてきました.... 私は非常に多くの、ぐちゃぐちゃなAntビルドスクリプトを見てきました。少なくともMavenは、一匹の獣と一つの哲学を手なずければ良いだけです。 Antは、多くの頭を持つランダムな獣です。
• Bryan Taylor(source) --Mavenには確かに、いくつかの革新的なアイデアがあります。しかし、私を震え上がらせるいくつかのものも同時に存在します。Mavenが拠り所としている"設定よりも規約"が、Ruby on Railsの流行よりも前に遡るにもかかわらず、それを発明したという全ての栄誉は後者が手にしています。そこには理由があるのです。
  

あなたはどう考える？

原文はこちらです：http://www.infoq.com/news/2008/01/maven-debate