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