動的クラスパスは、PDE が Eclipse 3.0 のプラグイン・プロジェクトのビルド・パスを見つける方法です。
Q: クラスパスの安定度とは
A: クラスパスの安定度とは、開発者によるセルフ・ホスティングの選択に関する
クラスパスの変更の尺度です。 理想的には、ワークスペース内でのソース・プロジェクトによって
補完されるかどうかに関係なく、クラスパスが変更されることは望ましくありません。 バイナリー・プロジェクトのセルフ・ホスティングは、
安定度のよいクラスパスを提供し、すべてのクラスパスにはプロジェクト参照のみが
含まれます。 それと比較すると、外部プラグインのセルフ・ホスティングが提供するクラスパスの
安定度は高くありません。 外部ライブラリーのローカルなインストール・ロケーションに関しては
それでも安定していますが、リポジトリーを通して共有するには、ソース・プロジェクトとしての
プラグインのリストがチームのすべてのメンバーに対して一定でなければなりません。
2.0 以降、ファイル・システム上のプラグイン・ロケーションに対してプラグイン・バージョンが 追加されたため、外部プラグインを使用するときのクラスパスの安定度はさらに低下しました。
Q: バイナリー・プロジェクトの方がよりよい安定度のクラスパスを
提供するのであれば、常にバイナリー・プロジェクトを使用してはどうでしょうか?
A: インポートされるプラグインの数が比較的少ない場合は (数十)、インポートされた
バイナリー・プロジェクトを使用するセルフ・ホスティングはよい選択です。 プラグインが
数百にもなる大規模な製品の場合は、まとめてインポートすることはできません。
一般に、
そのような製品の開発者は、小数のソース・プロジェクトと、それに直接関係する数十の
バイナリー・プロジェクトをセルフ・ホストし、それ以外のすべては外部プラグインとして
セルフ・ホストします。 純粋に理論的な観点からは、少数のソース・プロジェクトを
コンパイルできるようにするために大量の外部プラグインをインポートすることは、
時間とリソースを浪費する不適切な方法であると考えられます。
Q: (バイナリー・プロジェクト/外部プラグイン) のセルフ・ホスティング方式が
ベターであると思います。 これらを一緒に使用すると、何か不適切なことがあるでしょうか?
A: 静的クラスパス (バイナリー・プロジェクトまたは外部プラグインを使用) を使用すると、
セルフ・ホスティング方法が固定され、他のすべてのユーザーがそれを使用しなければならなくなります。
Q: 動的クラスパスとはどのようなものですか?
A: 動的クラスパスとは、プラグイン依存関係に関連のあるプラグイン・プロジェクト・クラスパスの
部分が JDT クラスパス・コンテナー・テクノロジーを使用して動的に計算される PDE 機能です。 動的クラスパスの
解決は「ジャスト・イン・タイム」で行われ、ワークスペースの状態によって常に最新の状態に維持されます。
さらに、
クラスパス解決の動的性質により、PDE は変化に対応でき、セルフ・ホスティングの方法に関係なくクラスパスは常に
正しくなります。
Q: 動的クラスパスのクラスパス安定度とは
A: 極めて優れています。 必須プラグインに対するすべてのエントリーは 1 つのクラスパス・コンテナー・エントリーに
置き換えられるので、クラスパスは常に同じになります。
Q: 動的クラスパスはどのように役に立ちますか?
A: 動的クラスパスを使用すると、セルフ・ホスティングのスタイルについて事前に決定する
必要がありません。 バイナリー・プロジェクトが存在する場合には、動的クラスパスはプロジェクト参照に
解決されます。 バイナリー・プロジェクトが存在しない場合は、外部プラグイン JARs に解決されます。 バイナリー・プロジェクトが
追加または除去されると、動的クラスパスは変更を追跡して対応します。 クラスパスを更新する必要はありません。 さらに
他のチームが CVS から 1 つ以上のプロジェクトを取得してコンパイルしたい場合であっても、使用されるプロジェクトの
個人用セルフ・ホスティング・スタイルを使用する必要はありません。
Q: PDE コアが動的クラスパスを解決するということは、正しい処理のためには PDE に依存するという意味ですか?
A: そのとおりです。 動的なので、クラスパスは .classpath ファイルにハードコーディングされているのではなく、
常に実行時に計算されます。 ただし、次のことを考慮してください。PDE は、実行時の状態をできる限り忠実に
反映するために、高度なアルゴリズムを使用してクラスパスを計算します。 JDT コンパイラーが開発時に認識す
ることと、クラス・ローダーが実行時に認識するものは可能な限り近くなければなりません。 通常、クラスパスを最新の状態に
維持する処理は、ユーザー自身が行うより、PDE コアが行う方が優れています。 コンパイルのために手作業で
クラスパスを変更する必要がある場合には、セットアップを間違える可能性が高く、プラグインが正しく
動作しないことがよくあります (SWT チームは例外です)。
Q: セルフ・ホスティングに対してバイナリー・プロジェクトのみを使用しています。 動的クラスパスに
切り替えることで何か失われるものはありますか?
A: ありません。 動的クラスパスが、ユーザー自身のセルフ・ホスティングの
調整についての選択に影響を及ぼすことはありません。 動的クラスパスは、特定のコンテキストに
おけるプラグイン依存関係を解決します。
引き続き外部プラグインをバイナリー・プロジェクトとしてインポートする場合は、前述のように、
動的クラスパスはプロジェクト参照に解決されます。
Q: 動的クラスパスをアクティブ化するにはどのようにすればよいですか?
A: ご使用の 2.1 のプラグインのクラスパスを一度だけアップデートしてください。 クラスパスが短くなり、すべての依存プラグイン参照が 1 つのコンテナー・エントリーに
置き換えられているのがわかります。 そのまま作業を続けることができます。 変更された .classpath ファイルを含めて、
ソース・プロジェクトをリポジトリーに必ずチェックインします。
Q: Ant タスク/サーブレット/JSP をコンパイルするための追加クラスパス・エントリーがあります。
A: クラスパス計算の一部として、PDE は、build.properties ファイルの jars.extra.classpath プロパティーを
考慮します。 ビルド用に正しくセットアップした場合、PDE は正しいクラスパスを生成します。
Q: 動的に計算されたクラスパス・エントリーを扱うにはどのようにすればよいのですか?
A: まれなことですが、動的クラスパス・エントリーを取り扱う必要がある場合は、
「プロパティー」>「Java のビルド・パス」>「ライブラリー」タブを使用します。 「プラグイン依存関係」ノードを展開し、そこにあるエントリーを操作します。
Q: ライブラリーに対して計算されたエントリーの一部にソース添付がありません。 手動で追加できますか?
A: PDE は、ほとんどのライブラリーに対してソース添付を計算します。 ただし、ソースの ZIP が
命名規則に従っていないために、自動的なソース添付で問題が発生することがまれにあります。 このような
エントリーに対しては、ビルド・パス・プロパティーのダイアログにおいて手動でソースを添付できます。
Q: 手動で行ったソース添付は、次に PDE がクラスパスを動的に計算すると無効になりますか?
A: いいえ。 PDE は、このような手動による添付を追跡し、ライブラリー・パスが変更されていない限り、
動的な計算の後で手動添付を再度適用します。
Q: SWT 開発者は動的クラスパスを使用できますか?
A: 残念ながらできません。 SWT チームが使用する固有のセルフ・ホスティング・セットアップでは、
さまざまな環境に対するクラスパスがリポジトリーに保管され、作業しているプラットフォームに応じて、
プロジェクトでは .classpath に名前が変更されます。 そのセルフ・ホスティング方法を引き続き使用する必要があります。