このセクションでは、3.2 のメカニズムと API を採用するように 3.1 プラグインを変更する場合に必要な変更について説明します。
Eclipse 3.2 は、起動構成とリソースを関連付けるための、新しいインフラストラクチャーを提供します。 このマッピングによって、プラットフォームが起動構成上でリソース・ベースのフィルタリングを行うことが可能になり、また関連したプロジェクトが削除されたときに、プラットフォームがオプションで起動構成を削除することが可能になります。 起動ダイアログが拡張され、閉じられた、あるいは削除されたプロジェクトに関連した構成を、オプションで非表示にするフィルターのセットをサポートするようになりました。 また、起動ダイアログは、アクティブなワークベンチ・ウィンドウ内の選択済み作業セットをベースとしたフィルタリングをサポートします。これは、起動ダイアログ内で選択することもできます。
起動構成のためのリソース・マッピングを管理するのは、クライアントの責任です。
API が ILaunchConfigurationWorkingCopy
に追加されて構成と関連するリソースを設定するようになり、また、API が ILaunchConfiguration
に追加されて、構成と関連するリソースを入手するようになっています。
例えば、起動タブ、起動ショートカットおよびリファクタリング登録プログラムは、マイグレーション中に考慮されなければなりません。
起動構成を作成または変更するコードも、リソース・マッピングを更新する必要があります。
Eclipse 3.2 は、起動構成をマイグレーションして新しいツールと互換性があるようにするための、新しいインフラストラクチャーを提供します。
例えば、Eclipse 3.2 では、起動構成上でリソース・ベースのフィルターを実行するために、サポートが追加されました。
起動構成は、この新しい機能に効果を与えるリソース・マッピングを提供するために、アップグレードされる必要があります。
ユーザーは、
「実行/デバッグ」>「起動」
>「起動構成」設定ページから、「Migrate」ボタンを押すことによって、ワークスペース内で起動構成を、手動でマイグレーションできます。
新規のオプション・マイグレーション委譲属性が、launchConfigurationTypes
拡張ポイントに追加されて、新規インターフェース ILaunchConfigurationMigrationDelegate
を実装するクラスを指定します。
マイグレーション委譲には、マイグレーション候補を識別して、それらをマイグレーションする責任があります。
新規のオプション属性が launchModes
拡張ポイントに追加されて、カスケード起動メニューのアクション・ラベルの外部化を適切にサポートするようになっています。
起動モードをコントリビュートするクライアントは、適切なラベルを指定して、「実行」のような起動カスケード・メニューのために使用する必要があります。
新規属性は launchAsLabel
と呼ばれます。
適切なラベルが、実行、デバッグおよびプロファイル起動モードのためのプラットフォームによって提供されました。
下位互換性の場合は、新規属性が起動モードに対して指定されていない場合は、以前のように、「{0} As
」を持つ MessageFormat を介して、カスケード・メニュー・ラベルが生成されます。
関連バグ 105235 を参照してください。
ICU4J は、Unicode、ソフトウェア、グローバリゼーション、および国際化対応に、より包括的なサポートを提供する Java ライブラリーのセットです。 この機能性を Eclipse コミュニティーに提供するために、ICU4J が Eclipse 3.2 のプラットフォームのビルドに追加されました。 com.ibm.icu という名前のプラグインとして、ビルドに表示されます。 Eclipse プラットフォームは、Eclipse 3.2 で ICU API を使用します。
アプリケーション・コードのマイグレーションを付加的に行うことができます。これは、ICU4J 使用の利点を得るために必ずしもすべての ICU4J 機能を採用する必要はないことを意味します。 ICU4J を使用するためにユーザーのコードをマイグレーションする方法について詳しくは、Eclipse Wiki の ICU4J ページを参照してください。
ICU4J プラグインの追加により、約 3MB の追加占有スペースが必要になります。 ICU4J 機能の採用よりもアプリケーション・サイズを重視する場合、アプリケーションによっては ICU4J の組み込みが望ましくない場合があります。 このような場合、Eclipse プラットフォーム・ビルド・ページから置換プラグイン (com.ibm.icu.base) を使用することができます。プラグインをダウンロードして、/plugins ディレクトリーから com.ibm.icu プラグインとそのソース対応物を除去し、置換プラグインにドロップインします。 Eclipse プラットフォームは ICU API for 3.2 を採用しているため、単に ICU プラグインを除去すると、プラットフォーム・コードでコンパイル・エラーが発生するので、このようにする必要があります。 置換プラグインのサイズは約 100KB で、ICU4J で最も一般的に使用されるクラスおよび API のデフォルト JDK の実装のみを呼び出します。 ICU 置換プラグインの使用に関する詳細は、再度、Eclipse Wiki の ICU4J ページをお読みください。
JFace で ICU4J をサポートするには、API で ICU クラスの参照を防ぐために、いくつかの独自の API を追加する必要がありました。 これにより、以下のものが追加されました。
org.eclipse.jface.viewers.ViewerComparator
と呼ばれる新規クラス。そのうち org.eclipse.jface.viewers.ViewerSorter
は現在サブクラスです。
org.eclipse.jface.viewers.StructuredViewer
への 2 つの新規メソッド。org.eclipse.jface.viewers.ViewerComparator
の追加をサポートします。ViewerSorter
クラスには、java.text.Collator
を戻す public メソッド getCollator()
があります。
このメソッドは API であるので、ICU コレーターを使用するためにそれを簡単には変更できませんでした。
また、ICU 上の直接のプラグイン依存関係は、(SWT で) JFace がスタンドアロンで使用されるのを防止するため、ICU クラスは、API (シグニチャー) の一部にすることはできません。
これらの制約に対応するために、ICU コレーターではなく、java.util.Comparator
を使用する ViewerComparator
クラスが追加されました。
ICU コレーター・クラスが java.util.Comparator
を実装するので、このクラスが追加されました。これにより、いずれの StructuredViewer
も java.text.Collator
ではなく ICU コレーターを使用できますが、JFace は、ICU4J プラグインへの依存関係を追加する必要はありません。
StructuredViewer
に追加された 2 つの新規のメソッドは、ViewerSorter
ではなく ViewerComparator
を通してビューアーのコンテンツをソートするために ICU コレーターの使用をサポートします。
現在、いずれの StructuredViewer
も、getSorter()
および setSorter(ViewerSorter)
メソッドではなく、これらのメソッドを使用して、ビューアーのソーター (コンパレーター) を get/set することをお勧めします。
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
org.eclipse.equinox.common バンドルには、共通名を持ついくつかの新規 API クラス (例えば、Assert
および ListenerList
) が組み込まれています。
コードに同じ名前を持つクラスがある場合に、ローカル・クラスとランタイムからのクラスの両方のインポートにインポート * ステートメントを使用すると、以下のエラー・メッセージが表示される場合があります。
The type ABC is ambiguous
インポートを編成し、適切なインポート元を選択することで、この問題は解決します。
新規ランタイム・プラグインにコードが移動されたため、カスタム・スクリプトが明示的に org.eclispe.core.runtime を参照する場合は、以下のプラグインを 1 つ以上追加しなければならない可能性があります。