Eclipseアップデートマネージャが、1つ以上のリモートサイトからEclipseのインストールがアップデートできるようにしている。これまで、 アップグレード時点のリリース(たとえば、3.3.0から3.3.1へ)や新機能のインストールが最も一般的な方法である。しかしながら、eclipse の実行可能ファイルのアップデートができないとか、ミラー障害に対処できないなど数多くの有名なリリースがあった。
これを解決するために、 BoFセッションのEclipseCon 2007(source)で新たなアップデート機構の種が蒔かれた。そして、その後Provisioning Platform(source)(簡単にはP2(source))が誕生した。それからインキュベーター(source)を経て、3.4M5でデビューとなった。
以前のEclipseアップデートマネージャとは違い、P2は包括的にバンドルおよび非バンドル両方のアップデートを可能にする。これによって、その他の システム(MinGW(サイト・英語)ベースのバンドルがWindowsにおけるGNU開発を可能にするWascana(サイト・英語)など)がP2を使用して、DLLや配布を形成するそ の他の実行可能ファイルのアップデートの道が開かれている。
P2は、Installable Unit(source)(インストールされるというよりはむしろ、インストール可能なもののメタデータである。Maven pom.xmlを考えてみるとよい)およびインストールされる成果物(バンドル、実行可能ファイル、ライブラリなど)の概念(source)を形式化する。さらに、これら は別々のロケーションに保管されているので、成果物自体をダウンロードする必要なしに、アップデートシステムがインストールされるものが何か(そして依存性が満たされるかどうか)を迅速に判断する。
Eclipse Communication Framework(source)によって、ダウンロードは処理される。また、複数のアルゴリズム(pack200, tar.gz)の1つを使用して、成果物の圧縮が可能であり、複数のミラーに及んでいるマルチスレッドダウンロードを使用可能である。ダウンロード中にアップデートサイトに問題が発生したら、以前のアップデートマネージャがエラーになったのに対し、P2は自動的に他のミラーにリトライし、データを探す。Eclipseおよびそのすべてのプラグインをインストールする5Mbインストーラー(source)のダウンロードさえも可能である。
これまでのEclipse Update Managerが抱えていた多くの欠陥を、P2が解決するのは明らかであり、よい(source)評価(source)を得ている。しかしながら、多くの作業が基礎となるインフラに集中し ている一方で、UIがようやく最近になってデプロイされ、まだ作業が継続中である。さらに、P2は古いUpdate Managerを段階的に廃止しており、3.4M7(source)はアップデートマネージャとの後方互換性を確実にする計画があるにもかかわらず、すべてが良いわけではないことは明らかである。
欠けている重要な機能の1つは、エクステンションロケーションへのインストール機能である。 IBMのDeveloperWorksの 記事(source)で説明されているように、多くの人がこれを使用し、さまざまな機能のサブセットをインストールできるようにしている。特にEclipseのインストール間でプラグインの共有セット(たとえばSubversiveまたはSubclipse)がインストールされるような場合は、特にそうである。これによっ て、Update Manageの回復を切望する人が出てきた(source)。インストーラーがMac OS Xで動作しないという事実はさておき、これまでのところ(source)悪い(ブログ・英語)印象(source)はほとんどない。
P2が将来の道であり、これまでのアップデートマネージャを超えた多くの機能があることは明確である。しかし、テストが必要でもあり、先週の3.4RC1(source)で、来月に予定されているGanymedeのリリースへのカウントダウンが始まっている。P2の準備が整い、そのうちに定着すると思うだろうか?
原文はこちらです：