単純自己ホスティングは、ほとんどのスタンドアロン状態で十分であり、 特にターゲットとして大きな製品を開発するために適しています。 しかし、以下のようにもっと進んだ解決が必要なシナリオがあります。
外部プラグインはワークスペースにないので、 それらは検索の有効範囲の一部にはなりません。 それゆえ、(インターフェース、クラス参照、インプリメンテーションなどに対して) 色々な検索は、 予期したより少ない結果を戻します。 ワークスペース・プラグインのクラス・パスの一部である外部ライブラリーのみが、 Java プラグインで可視になります。
1) と関係して、外部プラグインのソース・コードのブラウズは、 ワークスペース・プラグインで要求されるプラグインでのみ可能です。 他のプラグインは可視ではありません。
クラス・パスは安定していません。 ワークスペース内の相互依存のプラグインのいくつかを使用して作業している場合は、 PDE はプロジェクト参照としてこれらの依存性を表現します。 それとは対照的に、外部プラグインの依存性は、ECLIPSE_HOME 変数および外部 JAR を使用して表現されます。 これらのプロジェクトが、リポジトリーを使用して共用される場合は、 他の開発者は、ワークスペース内のすべてのプラグインが必要でなくても、この補足を複製するよう強制されます。
結論として明白なのは、すべてのプラグインがワークスペースにあった場合は、 これらの短所がアドレッシングされるということです。 予期したように検索が機能すると、ソース・コードはすべてのクラスで可視になり、 クラス・パスは、一定で、プロジェクト参照のみを含みます。 しかし、ソース・フォームの共用リポジトリーから製品全体を追加すると、 ダウンロードとコンパイルは必然的に遅くなります。 この理由から、バイナリー・プロジェクトの概念が紹介されています。
バイナリー・プロジェクトはソース・コードを含まない正規のプラグイン・プロジェクトです。 そのため、それらはコンパイルのとき、う回され、上記に挙げた補足をアドレッシングするためにのみ使用されます。 外部プラグインは、PDE インポート・ウィザードを使用して、ワークスペースに持ってきます。
バイナリー・プロジェクトをインポートする前に、 バイナリーの自己ホスティング用に PDE を構成することが重要です。 解決された参照に外部プラグインを使用しないので、それらを「設定」で使用不可にする必要があります。 その後、「ファイル -> インポート ...-> 外部プラグインおよびフラグメント」を使用して、「インポート」ウィザードを起動します。
ほとんどの場合、最初のページでデフォルト値を受け入れます。 デフォルトでは、「設定」内のセットとして、 ターゲット・ランタイム・ワークベンチの外部プラグインをインポートします。 代わりに、他のロケーションからプラグインをインポートすることができます。
「次へ」を押すと、ウィザードはすべてのインポート候補を計算して、 チェック・ボックスのリストで使用可能にします。選択するプラグインの実際のセットは、 自己ホスティングの方法によります。
ターゲット・プラットフォームにまだ存在しないプラグインで作業している場合は、 すべての選択項目を選択します (「全選択」)。 リスト上のプラグインのいくつかがソース・フォームのワークスペースにすでにある場合は、 「既存プロジェクト」、次に「逆選択」を押します。 これは、まだワークスペースにないすべてのプラグインを選択することになります。
「終了」を押すと、選択されたプラグインがワークスペースにインポートされます。 PDE はそれらのクラス・パスも設定し、ソース・アーカイブをライブラリーと関連付けるので、それらをブラウズあるいはデバッグすることができます。
ワークスペースに大量のバイナリー・プロジェクトがあると、 ソース・プロジェクトから離れて、それらを語ることは困難です。 PDE は、この問題を処理する補足的な方法を 2 つ提供します。 PDE はラベル修飾プログラムを提供して、バイナリー・プロジェクトにはっきりマークを付けるために、 「バイナリー」アイコンのオーバーレイを正規のプロジェクト・アイコンに追加します。 「ワークベンチ -> ラベル修飾」のもとで「設定」内でアイコンをオンにすることができます。 さらに、PDE は、バイナリー・プロジェクト・フィルターを「Java エクスプローラー」ビューに与えます。 フィルター機能が働くと、バイナリー・プロジェクトが隠され、作業しているもののみが残されます。