EclipseでMavenを生かす

EclipseとMavenから最善のものを引き出す

Mavenは、汎用のビルド・システムとして認知されつつあり、またJava™技術を追い越し始めています。この記事はMavenのチュートリアルではありませんが、Mavenと他の技術を比較しながら、MavenとEclipseはどういう点で一致するのか、両者を共に生かすためにはどうすべきか、などについて解説します。

Gilles Dodinet (gdodinet@karmicsoft.com), Research and Development Engineer and Consultant, Karmic Software Research

Gilles Dodinetはここ数年来、J2EE(Java 2 Platform, Enterprise Edition)のコンサルタントとして働いています。2004年からは、KarmicSoftの研究開発エンジニアとして、.NETコンポーネント・アセンブリ・ツールに携わっています。Eclipse開発者としての経験が豊富であり、Mevenideに傾倒している一人です。彼はこの記事を校閲してくださった、Michel ZamとMilos Kleintに感謝しています。



2005年 5月 24日

ここ1年ほど、Javaの世界では、Mavenは単なる流行以上のものとなりました。Mavenは2001年以来、ビルド・ツールの領域におけるパイオニアでした。初期の頃は、MavenはよくAntに例えられました。MavenとAntに似た点が多いことには誰もが気付くことを考えれば、これは自然に思えるかも知れません。例えば、両者ともXMLスクリプトが使えます。どちらのツールも成果物を生成し、また両者とも、プロジェクトや、ターゲット対ゴール、depends対prereqsなど、分類法や概念に関して一部を共用しています。しかし、両者は、本質的に大きく異なるものです。Antは単なるXMLスクリプト・ツールですが、Mavenは、POM(project object model)という概念に焦点を当てた、汎用のビルド・ツールです。POMでは、ゴールと呼ばれる、キメの粗いビルド指向タスクを公開します。ゴールは、ビルド手法の開発やベスト・プラクティス実装のための指針を提供するものです。

ある面で、Mavenは、末端ながらソフトウェア・ファクトリー・ツール・ファミリー(参考文献)に属するものです。もっと正確に言えば、ソフトウェア・ファクトリーという領域の中では、Mavenのようなビルド・ツールが必要だということです。

ソフトウェア・ファクトリー

ソフトウェア・ファクトリーは、開発の自動化レベルを大幅に向上することによって、それほど高価でない、そして、より信頼性の高いアプリケーション開発手法を提供するもの、と言うことができます。Software FactoriesのWebサイトによると、「ソフトウェア・ファクトリーというのは、特定種類のアプリケーション構築のための処方箋に基づいて、拡張性のある開発ツールを、・・・パッケージされた内容と・・・指針とによって設定するソフトウェア製品群です」(参考文献)。ソフトウェア・ファクトリーは、次の3つの概念を中心に構成されています。

  • スキーマ。アプリケーションを構成する様々な成果物の構造と、それらの相互動作を記述するメタデータを提供します。
  • 1つ以上のテンプレート。スターター・キットと、アプリケーション構築に必要なもの全てを提供します。
  • 拡張可能開発環境(extensible development environment)。コンポーネントの設定、カスタム化、組み立てに使われます。

今日、こうしたツールは、その価値を認識するツール・メーカーや開発者、そしてソフトウェア編集者から、次第に注目を浴びるようになっています。こうしたツールはソフトウェア開発プロセスの産業化を促進し、市場投入までのコストと時間を削減するものであり、その結果、生産性が向上し、また進化への要求に迅速に対応できるようになります。

Mavenの主な機能を細かく見て行くと、Mavenとソフトウェア・ファクトリーとの間の類似性に気が付くでしょう。Mavenでは、プロジェクト構造を記述するためのメタデータとしてPOMを使い、genappプラグインを通して拡張可能プロジェクト・テンプレートを取得します。Mavenの持つ柔軟性とオープンな性格を考えれば、ソフトウェア・ファクトリー・プラットフォームのコア・コンポーネントとしてMavenを統合することは、容易に推測できることです。しかし、それは別の話題です。類似性は、まだ完全ではありません。今日のMavenには専用の開発環境が欠けており、領域特有の、あるいは企業特有のプラグインやテンプレートを作ることや、プロジェクトを手軽に構成したり振る舞いをカスタム化したりすることは、まだ手軽にできません。

しかし、Mavenの基本的な目標というのは、ビルド・プロセスを標準化することであり、またCBTD(code-build-test-deploy)のサイクルに品質と再現性をもたらすことです。またMavenはメトリックスも生成できるため、開発状態を理解するための助けになります。CBTD存在論は、ソフトウェア・エンジニアリングの分野では新しいものではありませんが、この存在論をMavenによって標準化することができ、またこれを抽象化することによって、全体的な実体を視覚化できるようになります。様々なプロジェクトが複雑になり続けている実態から、標準化は緊急の課題です。この、拡張ビルド(extended build)の概念を、ここではメタ・ビルドと呼ぶことにしますが、メタ・ビルドは、さらに上のレベルにまで品質を高めるために非常に重要なものとして認識されています。連続的統合(continuous integration)は、この概念の上に構築されていますが、同時に、IDEのコンテキスト外でも構築できる、ということも示唆しています。


曖昧な境界線

Java技術に関係した人であれば誰でも、Eclipseのことを聞いたことがあるでしょう。2001年の中頃に最初のバージョンが出て以来、Eclipseは(Java開発者に限ったわけではありませんが)、特にJava開発者が好んで選択するIDE(integrated development environment)となるまでに成熟しています。Eclipseはオープンな、そして言語に中立なプラットフォームであり、教育や研究のプロジェクト用のベース・プラットフォームとしても使われています。そして、そうしたプロジェクトの一部はEclipseコンソーシアムに寄贈されています(参考文献)。MicrosoftRがソフトウェア・ファクトリーの手法を取ったのと同様、Eclipseコンソーシアムは、モデル駆動開発(MDD: model-driven development)の方向に進んでおり、新しいプロジェクト、MDDi(Model Driven Development Integration)に対する提案が最近公開されました。この提案によると、「Eclipse MDDiプロジェクトは、様々なモデリング言語(Unified Modeling LanguageあるいはDomain-Specific Languages)をサポートすべく作られたプラットフォーム、及びモデル駆動手法を実現するためのものです。」

最近のツールでは、様々な機能が完全にスムーズに統合されるようになっていますが、MavenとEclipse(単純なIDEでさえ)も例外ではありません。つまり、一見すると、ビルドという観点から両者は重なるように思えます。これを図1に示します。

図1. 拡張ビルドの概念
図1. 拡張ビルドの概念

図1は、先に議論した拡張ビルドの概念を、視覚的に説明しています。プロセス全体の中には、先に定義した通り、幾つかのタスクが含まれ、メタ・ビルドのインスタンスを表しています。タスクは、次の2つのタイプのいずれかです。アトミック・タスクはキメが細かく、コンテキストに依存しません。アトミック・タスクの2つのインスタンスは、ほとんど違いがありません。一方、マクロ・タスクは複合タスクであり、マイクロ・タスクのコンテナーとして動作します。

拡張した意味でのビルドは、マクロ・タスクのみを相手にし、アトミック・タスクは設定の状態によってトリガーされます。これはつまり、システムに関してユーザーが高位レベルのビューを持つことを意味し、システムの維持と進化が容易になるということです。

さらに、MavenもEclipseもオープンであり、プラグインを使えば、必要に合わせて容易に拡張することができます。しかし、両者が似ているのは、ここまでです。両者が対象とする相手は、同じではないのです。Eclipseのエンドユーザーの大部分は開発者ですが、Mavenが主に対象にしているのはビルド・マネージャーです。にもかかわらず、Mavenはコマンドライン・ツールです。Jason Van Zyl(Mavenの生みの親であり、アーキテクトでもあります)の下でGUI(graphical user interface)が開発されつつありますが、現在のところMavenには、設定ファイルを作ったり更新したり、あるいは1回のマウス・クリックでビルドを起動する、といったタスクの実行を助けるようなGUIは何もありません。

上で述べたような典型的なビルド・シーケンスは、EclipseではMavenほどスムーズではありません。Eclipseは本質的に開発の環境であることから、人の要素が絡み、ビルド・プロセスは不連続なものとなります。つまり、コンパイルが成功した後に必ずテストが実行されるわけではなく、全てのテストは必ずしも同時には実行されず、一部のマイクロ・タスクはスキップされる可能性がある、等々です。こうした変動要素のために矛盾が生じやすく、だからこそ開発者は、完全なビルド・シーケンスを少なくとも1日に1度は実行し、何も壊していないことを確認する必要があるのです。

しかしEclipseは拡張可能なプラットフォームであり、幅広いユーザー・コミュニティーによってサポートされています。そのため、EclipseはMaven駆動の開発のホストとして、開発者とビルド・マネージャーが単純な方法で協力するための理想的な候補と言えます。


MavenをEclipseの中に統合する

Mevenideというのは、Codehausがホストするプロジェクトであり、最も広く使われるIDEの中にMavenを統合することによって、Mavenを単純に使えるようにすることを目標にしています(参考文献)。現在のところ、Borland SoftwareのJBuilderとNetBeans、そしてEclipseがサポートされています。他のプロジェクトでも、部分的にMavenをEclipseに統合しているため、Mevenideと一部の機能(例えばMaven Workshopなど)を共有しています。しかしMavenの使いやすさを増すことの他に、なぜこうしたプラグインが必要なのでしょう。

Eclipse用のMevenideは、Mavenの複雑さの一部を覆い隠し、またチーム環境での協力作業を改善するようなツールやビューを提供することによって、生産性を向上させます。ビルドが既にMaven化されている場合であれば、協力作業の観点から見て最も便利な機能は、EclipseプロジェクトのメタデータとMavenのメタデータ間の双方向同期化(bidirectional synchronization)でしょう。もし開発者が、Eclipseに依存関係を追加した後でPOMの更新を忘れたとしたらどうなるでしょう。もしリファクターが、Mavenにまで伝わっていないとしたらどうでしょう。ビルドは失敗してしまうかも知れず、一部のユニット・テストが行われないかも知れません。ですから、EclipseとMavenのメタデータの同期を保つことには、本当に必要なのです。Mevenideはメタデータの変更をリスンし、メタデータの不一致を容易に識別できるようにします。それによって、ビルドがひどく破損するのを防ぐのです。

しかし、POMは、依存関係とプロジェクト・レイアウトのためだけのものではありません。POMには、バージョン番号や名前、ID、ソース・リポジトリー位置など、非構造的なプロジェクト管理情報も含まれています。Eclipseのメタデータは、必ずしもこうした情報の全ては反映しません。そこで、別の編集方法が必要になります。Mavenideは、そのためにグラフィカル・エディターを提供しています。ですから、生のXMLを手動で編集するという、退屈で間違いやすい作業を避けることができ、POMのメンテナンスが容易になります。意味で区切られたPOMの各セクションはエディター・ページとして表現されるため、モデルをグローバルに読みやすくなります。さらにMevenideには、POM作成という退屈なプロセスを最小限にするために、非常に容易で拡張性の高いPOMテンプレート機構を用意しています。

Eclipseの中からMavenを実行するという機能は、Mevenideのようなプラグインでは、ごく簡単です。実行すべきタスク(Mavenの用語ではゴールです)、例えばMavenプラグインを通してグローバルに定義されたタスクやプロジェクト依存のタスク、を選択することもできれば、ビルドに敏感な変数を定義することによって、ビルドをカスタム化することもできます。関係するオプション(つまり、IDEという意味合いで関係するもの)のみが表示され、ビルド・ログは、他のプラグインと同じように、Eclipseコンソールに出力されます。その結果、コンソールとEclipseの間を何度も行ったり来たりする必要が無くなるため、この機能は重要です。

Mevenideには、他にも便利な機能が数多く統合されていますが、ここに挙げたものほど重要ではありません。例えば、与えられたゴールとファイル・パターンの間の関係を定義できるため、こうしたタスクは、ワークスペース変更の差分次第で順次実行することができます。また、成果物リポジトリーをブラウズしたり、与えられた成果物を名前で検索したりすることもできます(成果物というのはビルドの結果であり、JARファイルの場合もあれば実行可能ファイルの場合もあり、あるいは完全なWebサイトである場合もあります)。その後は、Mevenideサイトに行けば、機能の完全リストを見ることができます。

しかし、1つの問題が残ります。確かにMavenideによって生産性が向上し、使いやすくなりますが、ある特定な状況に適切なのはどのツールなのか、よく考える必要がある、という点です。Maven ConsoleでMavenセッションを実行しては、時間がかかりすぎるかも知れません。ですから生産性を向上するために、コーディング・セッションの間はJUnitに統合されたEclipseサポートを使ってテストを実行し、Eclipseの内部コンパイラーを使って実行可能ファイルを生成するようにすべきでしょう。しかし、ソース・リポジトリーに何かをコミットする前には、POMが同期されていることを確認し、不必要な .classpathや .project修飾をロールバックする必要があります。つまり、もしこうしたファイルがソース・コントロールの下にある場合には、です。これは議論のある話題であり、Martin Van den Bemtのblogで議論されています(参考文献)。


まとめ

MavenとEclipseは性格の異なるものですが、ビルドの観点から見ると、重複する部分があります。両者の違いは大きいかも知れませんが、そうした違いは容易に解決することができます。最終的には、両者を協調させるための努力によって、大きなものが得られるでしょう。Mavenideのようなツールによって、MavenとEclipseをスムーズに協調させ、同期させることができますが、与えられた開発段階ではどのツールが最も適切かは、常に意識する必要があります。

Mavenは、プロセスの品質向上のために鍵となる要素として認識されつつありますが、Mavenが第一級のIDE市民となるまでには、開発環境への統合、特にEclipseへの統合には、多分に改善の余地があります。その統合が実現するまでの間は、例えばグローバル開発プロセスの中に緊密に統合するためにMavenを使うなど他の使い方を考えたり、あるいは、そうした使い方の実装のためにEclipseのような拡張性を持った環境をどう役立てるか、などを考えたりすることができるでしょう。

このシリーズの次回の記事では、Mevenideの機能を詳しく見ながら、このツールを使ってベスト・プラクティスを実装する方法や、MavenとEclipseの両方から最善のものを引き出すための方法などを解説します。

参考文献

  • Apacheには、Mavenを使い始めるための資料や情報が豊富に用意されています。またベスト・プラクティスも幾つ幾つか提供しています。
  • Jack Greenfieldその他によるSoftware Factories: Assembling Applications with Patterns, Frameworks, Models and Toolsは、ソフトウェア・ファクトリーを詳細に論じており、こうした技術を実現するための鍵となる要素を解説しています。
  • Software factories Web siteでは、ソフトウェア・ファクトリーの理論的根拠を示しています。
  • Eclipse.orgは、Eclipseプラットフォーム・プロジェクトや、その他の技術プロジェクトをホストしています。
  • Jean Bezivinその他によるFirst Experiments with a ModelWeaverは、ATLASグループが開発したModel Weaverプロトタイプを説明しています。
  • Eclipse Model Driven Development Integration (MDDi) projectは、モデル駆動開発(MDD: model-driven development)手法を応用するために必要な機能を提供するプラットフォーム実現の話題に特化しています。
  • Mevenide Eclipseプラグインと、関連のMavenプラグインをダウンロードしてください。
  • Martin Van den Bemtは彼のblogの中で、チーム環境における .project/.classpathの問題を議論しています。
  • 記事、「Eclipse Platform入門」(developerWorks, 2002年11月)は、Eclipseとプラグインのインストール方法を含めて、Eclipseの歴史と概要を解説しています。
  • Eclipse In Action: A Guide for Java Developers(2003年Independent Publishers Group刊)は、Eclipseを使うJava開発者にとって必読の書です。
  • developerWorksのOpen sourceゾーンには、広範な話題を網羅したハウツー情報やツール、プロジェクト・アップデートが用意されており、オープンソース技術の開発や、IBM製品上でオープンソース技術を利用するために大いに役立ちます。
  • 皆さんの次期Linux開発プロジェクトを、IBM trial softwareを使って革新してください。ダウンロード、あるいはDVDで入手することができます。
  • Developer BookstoreのOpen sourceセクションには、Eclipseに関する書籍を始め、オープンソースに関する技術書が割り引きで購入できますので、ぜひご利用ください。
  • developerWorks blogsに参加して、developerWorksコミュニティーに加わってください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source
ArticleID=237178
ArticleTitle=EclipseでMavenを生かす
publish-date=05242005