Platform Runtime and Plug-in Architecture

プラグインとはイクリプセ・プラットフォーム機能の最小単位であり、個別に開発や配布ができる。 普通は小さなツールは単一のプラグインとして書かれるが、複雑なツールはその機能をいくつかのプラグインに分割して保有する。 プラットフォーム・ランタイムとして知られる小さなカーネルを除いて、イクリプセプラットフォームの機能はプラグインに置かれている。 プラグインはJavaでコーディングされる。

典型的なプラグインはJARライブラリの中のJavaコードやいくつかの読み込み専用ファイル、イメージやウェブテンプレート、 メッセージカタログ、ネイティブコードのライブラリといったその他のリソースから構成される。 コードをまったく含まないプラグインもある。 このような例の1つは、HTMLページ形式のオンラインヘルプを提供するプラグインである。 1つのプラグインのコードライブラリや読み込み専用コンテントはファイルシステムの1つのディレクトリに一緒に置かれる。 それぞれが独自のディレクトリやURLに在する、 いくつかの分離された断片からプラグインを合成することを可能にするメカニズムも存在する。 これは国際化されたプラグインのために分離された言語パックを配布することに使用されるメカニズムである。

各プラグインは他のプラグインとの相互接続性を宣言するマニフェストファイルを持つ。 相互接続のモデルは単純である: プラグインは任意の数の名前付けされた拡張ポイントと、 1つ以上の他のプラグインの拡張ポイントに対する任意の数の拡張を宣言する。 プラグインの拡張ポイントは他のプラグインによって拡張されることができる。 例えば、ワークベンチプラグインはユーザーの嗜好に対する拡張ポイントを宣言する。 あらゆるプラグインがこの拡張ポイントへの拡張を定義することでそれ自身のユーザー嗜好を提供できる。 拡張ポイントは相当するAPIインタフェースを持つことを許される。 他のプラグインはこの拡張ポイントへの拡張を介してこのインターフェースの実装を提供する。 新しい拡張ポイントを宣言することや他のプラグインが使用する新しいAPIを提供することはプラグインの自由である。

スタートアップ時にプラットフォームランタイムは利用可能なプラグインの集合を発見し、それらのマニフェストファイルを読み、 そしてメモリ上のプラグインレジストリを構築する。 プラットフォームは名前による拡張宣言とそれらの相当する拡張ポイント宣言を適合させる。 何らかの問題、拡張ポイントを持たない拡張のような、は検出され、記録される。 プラグインレジストリの結果はプラットフォームAPIを介して利用可能である。 プラグインはスタートアップの後は追加することができない。

プラグインマニフェストファイルはXMLを収めている。 拡張ポイントは拡張で使用するために追加的な特殊化されたXML要素タイプを宣言することを許される。 これは拡張を供給しているプラグインが 相当する拡張ポイントを宣言しているプラグインと任意の情報を交換することを可能にする。 加えて、マニフェスト情報は提供しているプラグインを活性化、あるはそのコードをロードすることなしに プラグインレジストリから利用可能である。 この特性は何らかの特定のユーザーセッションで必要とされる限られたプラグインだけがインストールされる巨大基盤のサポートの鍵である。 プラグインのコードがロードされるまでは、それは取るに足らないメモリ上の痕跡であり、スタートアップ時の影響も無視できる。 XMLに基づくプラグインマニフェストはプラグインの創造を支援するツールを書くことを容易にする。 イクリプセSDKに含まれる、プラグイン開発環境(PDE)はそんなツールである。

プラグインは実際にそのコードの実行が必要になったときに活性化される。 一度活性化されると、プラグインはその拡張ポイントに対して提供されている拡張を発見、アクセスするためにプラグインレジストリを使用する。 例えば、ユーザー嗜好拡張ポイントを宣言しているプラグインは提供されているすべてのユーザー嗜好を発見し、 嗜好ダイアログを構築するそれらのディスプレイ名にアクセスする。 これはレジストリからの情報だけを使用して行われ、いかなる提供しているプラグインを活性化する必要はない。 提供しているプラグインはユーザーがリストから嗜好を選択したときに活性化される。 このやり方でのプラグインの活性化は自動的には起こらない; 明示的なプラグインの活性化のために少数のAPIメソッドが存在する。 一度活性化されるとプラグインはプラットフォームがシャットダウンされるまで活性であり続ける。 各プラグインはプラグイン独自のデータを保存するためのサブディレクトリを与えられる; このメカニズムはプラグインが実行と実行の間で重要な状態を維持することを可能にする。

プラットフォームランタイムはアプリケーションのために特別な拡張ポイントを宣言する。 プラットフォームのインスタンスがランチされたとき、アプリケーションの名前がコマンドラインを介して指定される: 最初に活性化される1つのプラグインがそのアプリケーションを宣言するものである。 前面に出る利用可能なプラグインの集合を決定することと、 プラグインの間の情報の重要な交換を、それらのいずれをも活性化する必要なしにサポートすることで、 プラットフォームはそれが操作しているコンテキストに関する適切な情報の豊富な源を各プラグインへ提供するすることができる。 このコンテキストはプラットフォームが実行していいるときは変更できない、 このため、コンテキストが変化した時にプラグインに通知する複雑なライフサイクルイベントは必要ない。

予測できないプラグインの活性化順から生じるありがちなバグの因でもある、長いスタートアップシーケンスは回避されている。 イクリプセプラットフォームは標準のJava仮想マシンの単一の呼び出しで実行される。 イクリプセプラグインは単独でそのクラス(と同梱されるJavaリソース)のローディングに対応できる自分のJavaクラスローダに割り当てられる。 イクリプセプラグインは直接にアクセスするクラスが在する他のプラグインに対する自身の依存性を明示的に宣言する プラグインは自身のライブラリ内のパブリックなクラスやインターフェースの可視性をコントロールする。 この情報はプラグインマニフェストファイルで宣言される; 可視性のルールはプラグインのクラスローだの実行時に強制される。

プラグインのメカニズムはイクリプセプラットフォーム自身の分割に使用される。 実際に分割されたプラグインがワークスペース、ワークベンチ、その他を提供する。 プラットフォームランタイムでさえそれ自身が自分のプラグインを持つ。 プラットフォームの非GUI設定はそれに依存するワークベンチプラグインや他のプラグインを単に省略できる。 イクリプセプラットフォームのアップデートマネージャは新しい機能や既存の機能の更新された版をダウンロードしインストールする。 (機能とは一緒にインストール、更新される関連するプラグインのグループである) アップデートマネージャは次回のイクリプセプラットフォームのランチで使用される利用可能なプラグインの新しい設定を構築する。 更新やインストールの結果が不満足を見つけると、ユーザーは前の設定にロールバックすることができる。

イクリプセプラットフォームランタイムはまた動的にオブジェクトを拡張するメカニズムを提供する。 「アダプタブル」なインターフェースを実装するクラスはそのインスタンスがサードパーティ製の振る舞い拡張をオープンすることを宣言する。 アダプタブルインターフェースはインターフェースやクラスを実装するアダプターオブジェクトに要求されることができる。 例えばワークスペースのリソースはアダプタブルオブジェクトである; ワークベンチはリソースに適合するアイコンやテキストラベルを提供するアダプターを追加する。 いかなるパーティも既存のアダプタブルオブジェクトのタイプ(クラスとインターフェースの双方)に振る舞いを追加できる。 プラットフォームに適合するアダプターファクトリを登録することで。 複数のパーティがそれぞれ異なった目的のために同じアダプタブルオブジェクトを独立して拡張することができ、 任意のインターフェースのアダプターが要求されたとき、プラットフォームはそれを作成するにふさわしいファクトリを同定し呼び出す。 このメカニズムはアダプタブルオブジェクトのJavaタイプだけを使用する(それはアダプタブルオブジェクトのメモリ上の痕跡を増加させない)。 あらゆるプラグインはこのメカニズムを既存のアダプタブルオブジェクトに振る舞いを追加したり、 他のプラグインが使用そして多分拡張するためのアダプタブルオブジェクトの新しいタイプを定義することに利用できる。

SWT