6月25日に行われたEclipse Ganymade（Eclipse 3.4）(source)にあわせてInfoQはEclipseの一連のサブプロジェクトを取り上げていく。今回取り上げるのはEquinox p2（Provisioning Platform）(source)で、これはEclipseベースのアプリケーションをプロビジョニングする（必要に応じて供給する）ためのフレームワークだ。InfoQはJeff McAffer氏(source)とPascal Rapicault氏(source)にp2とその役割について話を聞いた。
p2がEclipseにもたらすことについてRapicault氏が述べたのは、p2のバージョン1.0が既存のUpdate Manager（UM）を置き換えるように設計されているということだ。McAffer氏がいくつかの機能をあげた。
- 全ての利用可能なリソースについて自動的にダウンロードをリトライする
- 自動的に一番良いミラーサーバを選択する
- 複数のEclipseインスタンスでプラグインの共有を可能にするBundle Poolingと呼ばれる機構
- インストール処理をフルに管理できるようにする（exeやiniなど）
- Eclipseインスタンスを起動しないでもEclipseを管理したり更新できるようにする
- headless（GUIをもたないUI）や独自の更新ユーザインターフェースの作成を容易にするmake
- プラグインの依存性の検証。それによって、あるプラグインをインストールし起動する時に、それを動かすのに必要なプラグインだけをインストールする
- マルチスレッドダウンロードによるダウンロードの高速化
- 必要なプラグインだけインストールするため、インストール済みのプラグインの数を減らせる
- 複数のソースからプラグインを取得することのできるような優れた更新サイトを作る
- プロビジョニングプラットフォームということはEclipseを再インストールする必要がないということで、ただ更新だけおこなえばいい
- インストーラは通常のJavaアプリケーションとして実行したり、あるいはJava Web Startを使うことができる。このインストーラはEclipseの全ての面について設定を行えるように作ることができる
- エンドユーザが行うことを明確かつシンプルにする
p2が解決したUMの問題とはなんだったのか聞くと、上記の機能がUMの問題と密接に関わっているとMcAffer氏は語った。Rapicault氏はUMがEclipseプラットフォームの進化についていってなかったこと、そしてUMが開発チームでほとんど使われていなかったことを指摘した。p2の目標の一つはエンドユーザとプラットフォームディベロッパの両方にとって魅力ある選択肢になることで、Rapicault氏はこう述べた。
大勢の人にとって実際に役立つような今までUMになかった機能を取り込んだことをその人たちに気付いてもらい、その人たちが実際に使いながら役立つようなものになっていることを気付いてもらうのは大きな挑戦です。これは大変難しいことで、みなさんが用いてきたUMを使うための様々なワークフローを変えないといけず、私たちは今それをお願いしているとこです。
p2 は新しいオンラインインストールの機能もEclipseにもたらしている。これには数メガバイトのシンプルなインストーラやカスタマイズ可能なJava Web Startインストーラが使われる。後者はEclipse Packaging Projectで作られている新しいウェブベースのインストールウィザードに統合される予定だ。このようなインストーラはp2がEclipseベースのシステムやOSGiベースのシステムに提供する機能の「氷山の一角」にすぎないとMcAffer氏は言う。Rapicault氏は付け加えて、p2を拡張したいと考える人はp2が優れたモジュール性を持った構成要素でできていて、OSGiベースのデスクトップ/サーバー/モバイルデバイスのアプリケーションを管理できるようになっているが分かるでしょうと語った。McAffer氏はp2はEclipse仕様のテクノロジではないことを示唆して、ウェブアプリケーションやGUIのない環境でも動き、Eclipse IDEのような大きなアプリケーションの一部やスタンドアローンのプログラムとしても動くように設計されていると語った。McAffer氏はまた「任意のアプリケーションに応用するのを妨げるような設計や実装はされていません」とも付け加えた。
McAffer氏はウェブアプリケーション内でp2を動かすことについて詳しく話してくれた。
p2 はウェブアプリ内にパッケージすることができます。ご存知のとおりEclipseを支えるOSGi実装であるEquinoxは最近サーバサイドで広く使われるようになっています。いくつかのケースではアプリケーションサーバの実装として使われ、他のケースではアプリケーションの実装にOSGiモデルと Equinoxの機能が使われています。Equinoxのサーブレットブリッジを使えばWAR内でEquinoxとOSGiのパワーと柔軟性を利用することができます。たとえば、Equinoxとp2だけ含んだ小さな普通のWARをデプロイすると、ウェブアプリケーションを設定し実行するのにp2のプロビジョニング技術を利用できるようになります。そのアプリケーションは動的に拡張や更新がされるのです。
p2の開発においてはいくつかの大きな試練があった。InfoQがMcAffer氏とRapicault氏にその試練と解決策を聞くと、McAffer氏はこう答えた。
良い質問ですね。UMから多くの事を学び他のプロビジョニングシステムについて学べた点で開発チームは幸運に恵まれたといえます。私たちが直面した試練とそれを解決するためにしたことをあげましょう。
メタデータ － メタデータの構造と形式について私たちは直接的・間接的に数ヶ月費やしました。多くの人が最初に聞いてきたのは「p2のメタデータ形式（つまりXML）はどんな感じなんだい？」「スキーマを見せてくれないかい？」というものでした。基本的に私たちはこう答えました。「特に決めてません」「（それぞれに対して）ノー」形式を決めることの問題は、決めてしまうと「それだけが正しい」となってしまうことです。古いUpdate SitesもあればOSGi Bundle RepositoryもあればMavenのレポジトリもある今の世の中では、それは正しいとは限らないのです。エンドユーザはそれら全てに接続したいと思い、それ以上をしたいと思うものです。私たちの結論はAPIレベルでのメタデータを決めて、詳細な形式はレポジトリを提供する人たちが決めるというものです。レポジトリを提供するにはシンプルなインターフェースを2,3実装するだけです。もちろん私たちはp2の全ての機能が使えるようなレポジトリの実装を提供していますし、従来のUpdateサイトや他のレポジトリ実装に対してもp2は有効です。
レポジトリ － 私たちはp2が使われ採用されるためにはレポジトリの柔軟性がキーになると考えました。既存のデータや形式やシステムにp2が取って代わるつもりはありません。そのためメタデータとアーティファクト（ファイルのようなデータのエンティティ）構造を分けることが必須でした。そうした結果p2は大きな成功をおさめ、p2は新しいデータストアを作ることも既存のデータストアを利用することもできる柔軟性を得ることができました。私たちはp2全体に拡散するレポジトリを作ることにもしました。バンドル（OSGiでのコンポーネント）はインストールされた時にリポジトリに登録されますが、リポジトリは他の設定やシステムをプロビジョニングするのにも使うことができます。システムを構築するこのコンポーネント設定もまたレポジトリです。これを可能にするためp2の全体にわたってミラーリングの概念を採用しました。ミラーリングするために何かをダウンロードする必要はありません。その結果、システムをプロビジョニングする時に他の既にプロビジョンされたシステムも使うことができるのです。私たちはアーティファクト形式の概念の抽象化もしたので、1つのレポジトリで同じアーティファクトを異なる形式で格納することができます。例えば、標準JARやPack200を使ってパッケージされたJAR、アーティファクトの異なるバージョン間のバイナリ差分など、全てが共存可能です。システムにプロビジョニングを行う際にはp2が最も有効なものを選択します。
制約解決 － OSGiベースのシステムでは、表記可能な依存性というのは比較的シンプルなものですみます。しかし様々に異なる要素を含んだ現実のエンタープライズシステムとなると、どれを供給するか決定するのに必要な制約は多岐に渡ります。私たちが選んだのは一般的な「requires-provides」スタイルの制約システムでしたが、本当によかったのはシステム構築に必要なコンポーネントを選ぶのにpseudo-boolean型の制約エンジンを使ったことで、私たちはそのためにSAT4Jを採用しています。この基本的な仕組みは、制約をいくつものpseudo-boolean方程式と望ましい結果を表す重みの集合にマッピングすることです。これがSAT4Jに送られると解が出ます。この解はインストールしたりアンインストールしたり更新したりする必要のあるコンポーネントへ逆マッピングされてp2に伝えられます。これはシンプルで高速な方法です。様々な評価関数によってこの仕組みを最適化することができればより良くなるはずです。そのためスペースの面で最適化（最小設定でインストールする）したり変更面で最適化したりするような関数を書くことができるようになっています。多くの研究チームがこの手の方法を研究していますし、p2はその結果を利用できるよう設計されています。
柔軟なアーキテクチャ － Eclipseは組込システムからサーバサイドを便利に操作するためのリッチクライアントアプリケーションにいたるまで、様々な場面で使われています。それはつまり、柔軟に設定できるインフラのプロビジョニングに対して大きな需要があるということです。プラガブルなレポジトリ、異なるプロビジョニングポリシー、複数の転送経路、複数のマシンに分散するプロビジョニングロジック、リモート管理、など。これらを可能にするために設計と実装の両方で高いモジュール性のあるアプローチを取りました。Ganymedeにおけるp2の仕組みはUpdate Managerユーザのほとんどにとって珍しいものではないはずですが、その実は数多くの柔軟性を備えたものになっています。
そしてRapicault氏がこう付け加えた。
私にとっては、更新管理での互換性と同じく共住性（デフォルトではUMとp2は両方ともSDKに含まれる）も一番の課題の一つでした。UMは7年以上にもわたって使われ、システム管理のためのいろんな方法を提供してきましたし、それらの中でp2の方法にそぐわないものは特に問題になりました。このため私たちが見つけうるバグ、コード、その他ドキュメントについて発掘調査をして、ユースケースに漏れがないようにしました。これに関することでいえば、1年の内に、7年生きた旧来の種との共住は終わるはずです。
別の課題は「試作品」や「とても柔軟性のある最高にクールなプラットフォームを作る」という考えから抜け出し、ただ人々が使えるものを作ることに集中することでした。このために私たちはよく自分に「それはUMあっただろうか？」と問いかけました。このことが私たちを前に進めてくれました。
リゾルバも大きなチャレンジの一つでしたが、これはその問題自体がもつ難しさによるものでした。何ヶ月か調査をしてプロトタイプを作った後、非常によく似た状況でSATのソルバを使う方法についての論文を2つ見つけました。それが的確な解決方法だと感じられたので、私はSAT4Jを使ってプロトタイプを作ってみました。NP完全性に対処するソルバをEclipseにおくのは最も効果的な方法だとPMC（Eclipse PMC）が判断したことで、私たちはこの方法を取ることに決めました。それにSAT4JのチームメンバのDaniel Le Berre氏とAnne Parrain氏が私たちに参加して多大な協力をしてくれたのも幸運なことでした。私たちは2つのチームによる真のコラボレーションを行うことができました。それは置いておいて、私たちがこの方法を選択したことは大変喜ばしいことでした。おかげでソルバの機能をより利用して、将来のリリースでプラグインや製品を記述するための一連の方法を推進する計画を立てられたのですから。
初期の段階からコミュニティを形成するのも一つのチャレンジでした。ある意味、プロジェクトの誕生時点から継続してコミュニティと共に作業しないといけないことは、わりと私たちにとって新しいことでした。後に参加者となってくれる人たちのほとんどとプロビジョニングのワークショップで会えたこと、そしてEquinoxサミットで私たちのビジョンを共有し専門分野や関心分野を広げられたのはラッキーでした。それらは全て成功につながりました。p2をベースにした商業製品を既に開発した企業があり、他のいくつかの企業もp2ベースのインストーラによってEclipseベースのアプリケーションだけでなく他のものからも構成をおこなえる商用製品を作っているところです。
p2の今後のプランについて、McAffer氏は1.0のリリースではさらに進んだ開発を行えるインフラが整えられるという。ツーリング、プロビジョニングポリシー、パフォーマンス改善、より多くの実行環境への対応などが含まれ、より多くの状況でp2が使えるようになるだろう。Rapicault氏はコミュニティの拡大と、デスクトップとより統合できるような対策も予定されていると付け加えた。またMcAffer氏は、Eclipse IDEでサポートされているのにEclipseチームではサポートを講じてない言語があるが、p2チームはp2ベースのシステムを作るためにコミュニティから訪れたどんな言語の人たちに対してもサポートできる対策を行うと語った。
e4（Eclipse 4）との統合あるいは影響はどうか尋ねると、McAffer氏はこう述べた。
私は当初からp2はe4の成果だと考えていました。たまたま早い段階で姿を見せてEclipseの3.xでも利用することが可能になりましたが、私たちの設計思想にはe4的な考えも含まれているのです。e4ではより動的で、よりモジュール性があり、より分離性をもつように計画されています。これらの性質は大きな恩恵をもたらすとともに大きな試練ももたらします。p2はエンドユーザにとって敷居の低いものであるようにしたいと私たちは考えていますし、システムインテグレータはe4の高度に統合されたシステムを管理する力を人々に与えることができます。p2はe4に欠かせないものとなるでしょう。
原文はこちらです：http://www.infoq.com/news/2008/06/eclipse-ganymede-p2