Eclipse の変更に伴い、2.1 と 3.0 の間には互換性がなくなったため、プラグインはその影響を受けます。以下の項目で、変更された領域、および 2.1 のプラグインを 3.0 にマイグレーションする手順について説明します。2.1 のプラグインを 3.0 で実行していて問題が生じる場合は、ここを調べるだけで十分です。
プラグイン (およびプラグイン・フラグメント) のマニフェスト・ファイルのヘッダーは、該当するプラグイン・マニフェスト・バージョンを識別する新規の行を組み込むように変更されました。3.0 より前では、プラグインに、これら <?eclipse ...?> という行の 1 つが含まれていませんでしたが、3.0 以降では、常に 1 つ含まれている必要があります。この変更は、3.0 に移植されていない 3.0 よりも前のプラグインを、Eclipse ランタイムが確実に認識できるようにするためのものです。これにより、Eclipse ランタイムは、そのようなプラグインに、より高いバイナリー互換性を自動的に提供することができます。以下に、plugin.xml ファイルの一般的な形式を示します (fragment.xml もこれに類似しています)。
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
...
</plugin>
PDE 3.0 によって作成されたプラグイン・マニフェストは、自動的にこの形式になります。PDE プラグイン・マイグレーション・ツールを使用されることを強くお勧めします。 このツールは、2.1 のプラグインおよびプラグイン・フラグメントのマニフェストに、上で示した行を自動的に挿入し、この資料で説明しているその他の多くの変更にも対応しています。
このディレクティブを (手動で、または PDE を使用して) plugin.xml に追加する場合は、このファイルも更新して、このファイルが依存しているプラグインを明示的にリストする必要があります。 例えば、Eclipse 3.0 よりも前は、暗黙のうちに org.eclipse.core.runtime および org.eclipse.core.boot に依存していました。3.0 では、org.eclipse.core.boot は不要になっています。開発者は、org.eclipse.core.runtime または org.eclipse.core.runtime.compatibility を適宜選択する必要があります (またはどちらも選択しない)。
注: これは、Eclipse 3.0 による 2.1 のバイナリー・プラグインの実行方法には影響しない非互換性の 1 つです。
かつてはメインのプラットフォーム UI プラグインであった org.eclipse.ui プラグインは、汎用的な (すなわち、IDE 固有ではない) ワークベンチに API と拡張ポイントだけを提供するようになりました。オプションの IDE 固有の API および拡張ポイントは、他のプラグインに移動されました。
この変更の影響には、次の 2 つがあります。(1) 移動された org.eclipse.ui 拡張ポイントは、新規の拡張ポイント ID を持ちます。(2) 必要なプラグインのリストが変更されました。
以下の表の org.eclipse.ui 拡張ポイントは別のプラグインに移動したため、それらの拡張ポイント ID が変更されました。既存のプラグインが、移動された拡張ポイントに何らかの拡張を提供している場合は、プラグイン・マニフェスト・ファイルの <extension> 要素の「point」属性の参照は、対応する新規の拡張ポイント ID を参照するように変更する必要があります。 PDE プラグイン・マイグレーション・ツールは、これらの修正を行います。
注: これは、Eclipse 3.0 による 2.1 のバイナリー・プラグインの実行方法には影響しない非互換性の 1 つです。Eclipse 3.0 ランタイムは、3.0 よりも前のプラグインを (プラグイン・マニフェスト内に前述の <?eclipse version="3.0"?> の行が欠落していることを利用して) 自動的に検出し、これらの拡張ポイントおよびプラグインの依存関係の変更を自動的に補正します。
古い拡張ポイント ID |
新規拡張ポイント ID |
org.eclipse.ui.markerHelp | org.eclipse.ui.ide.markerHelp |
org.eclipse.ui.markerImageProviders | org.eclipse.ui.ide.markerImageProviders |
org.eclipse.ui.markerResolution | org.eclipse.ui.ide.markerResolution |
org.eclipse.ui.projectNatureImages | org.eclipse.ui.ide.projectNatureImages |
org.eclipse.ui.resourceFilters | org.eclipse.ui.ide.resourceFilters |
org.eclipse.ui.markerUpdaters | org.eclipse.ui.editors.markerUpdaters |
org.eclipse.ui.documentProviders | org.eclipse.ui.editors.documentProviders |
org.eclipse.ui.workbench.texteditor. markerAnnotationSpecification |
org.eclipse.ui.editors.markerAnnotationSpecification |
以下の表に、以前は org.eclipse.ui プラグインで提供されていて、別のプラグインに移動された API パッケージをリストします。(API パッケージ、クラス、フィールド、およびメソッドの名前は変更されていません。)場合によっては、API パッケージが複数のプラグインに分割されていることもあります。あるプラグインに対して可視になる API クラスは、そのプラグインが必要としているプラグインのリストで決定されるので、これらの変更により、API クラスに再アクセスするためには、既存のプラグインのマニフェスト内の "<requires>" 要素を調整する必要が生じる可能性があります。
この変更により影響を受けるのは、org.eclipse.ui プラグインに依存する (すなわち、プラグイン・マニフェストの <requires> セクションに <import plugin="org.eclipse.ui"/> が含まれている) プラグインだけです。それ以外のプラグインはすべて、影響を受けません。プラグインが影響を受ける場合は、<import> 要素を変更するか、追加の <import> 要素を追加する必要が生じる可能性があります。そうすることによって、プラグインが必要としているすべての API クラスがスコープ内に入ります。 プラグインには、そのプラグインが実際に使用するプラグインに対する依存関係だけを記述しておくことを強くお勧めします。不要な依存関係が含まれていると、Java クラス・ローダーがすべての依存関係のクラスを検索する必要があるので、実行時のパフォーマンスが低下します。(PDE プラグイン・マイグレーション・ツールは、依存関係を修復し、最小のセットを決定するのに役立ちます。)
API パッケージ |
2.1 プラグイン |
対応する 3.0 プラグイン |
org.eclipse.jface.text.* | org.eclipse.ui | org.eclipse.jface.text |
org.eclipse.text.* | org.eclipse.ui | org.eclipse.jface.text |
org.eclipse.ui | org.eclipse.ui | org.eclipse.ui, org.eclipse.ui.ide |
org.eclipse.ui.actions | org.eclipse.ui | org.eclipse.ui, org.eclipse.ui.ide |
org.eclipse.ui.dialogs | org.eclipse.ui | org.eclipse.ui, org.eclipse.ui.ide |
org.eclipse.ui.editors.* | org.eclipse.ui | org.eclipse.ui.editor |
org.eclipse.ui.model | org.eclipse.ui | org.eclipse.ui, org.eclipse.ui.ide |
org.eclipse.ui.part | org.eclipse.ui | org.eclipse.ui, org.eclipse.ui.ide |
org.eclipse.ui.texteditor | org.eclipse.ui | org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors |
org.eclipse.ui.texteditor.* | org.eclipse.ui | org.eclipse.ui.workbench.texteditor |
org.eclipse.ui.views.bookmarkexplorer | org.eclipse.ui | org.eclipse.ui.ide |
org.eclipse.ui.views.contentoutline | org.eclipse.ui | org.eclipse.ui.views |
org.eclipse.ui.views.markers | org.eclipse.ui | org.eclipse.ui.ide |
org.eclipse.ui.views.navigator | org.eclipse.ui | org.eclipse.ui.ide |
org.eclipse.ui.views.properties | org.eclipse.ui | org.eclipse.ui.views |
org.eclipse.ui.views.tasklist | org.eclipse.ui | org.eclipse.ui.ide |
org.eclipse.ui.wizards.datatransfer | org.eclipse.ui | org.eclipse.ui.ide |
org.eclipse.ui.wizards.newresource | org.eclipse.ui | org.eclipse.ui.ide |
Eclipse 3.0 プラットフォーム・ランタイムは OSGi に基づいており、org.eclipse.core.runtime および org.eclipse.core.boot という 2 つのプラットフォーム・ランタイム・プラグインの構造を変更する必要があります。
新規の org.eclipse.core.runtime.compatibility プラグインは、古い API と新しい API の間の実装上のブリッジを提供しており、かつては org.eclipse.core.runtime および org.eclipse.core.boot にあった、廃止された多くの API の新しいホームになっています。プラットフォーム・ランタイムの拡張ポイントは、再構築による影響を受けません。
既存のプラグインを 3.0 にマイグレーションする場合は、そのプラグインのマニフェストを更新して、Eclipse プラットフォーム・ランタイム・プラグインの新しい構造を反映させる必要があります。PDE プラグイン・マニフェスト・マイグレーション・ツールは、必要に応じて、org.eclipse.core.runtime.compatibility に依存関係を追加します。
(<?eclipse version="3.0"?> を使用して) プラグインを 3.0 としてマークし、そのプラグインで Plugin クラスを定義する場合は、プラグイン・マニフェストに <import plugin="org.eclipse.core.runtime.compatibility"/> を明示的に含めるか、または Plugin クラスでデフォルト・コンストラクターを定義してください。
注: これは、Eclipse 3.0 による 2.1 のバイナリー・プラグインの実行方法には影響しない非互換性の 1 つです。Eclipse 3.0 ランタイムは、3.0 よりも前のプラグインを (プラグイン・マニフェスト内に前述の <?eclipse version="3.0"?> の行が欠落していることを利用して) 自動的に検出し、プラットフォーム・ランタイムへのこれらの変更を自動的に補正します。
org.eclipse.xerces プラグインは不要になったので、削除されました。 XML 構文解析のサポートは J2SE 1.4 に組み込まれており、Xerces プラグインが存在しているとクラス・ローダーの競合が発生します。javax.xml.parsers、org.w3c.dom.*、および org.xml.sax.* API パッケージは、以前は org.eclipse.xerces プラグインが提供していましたが、現在は J2SE ライブラリーから利用できます。
org.eclipse.xerces プラグインを必要とするプラグインの場合は、そのプラグイン・マニフェストを変更して、上述の依存関係を除去する必要があります。いったん変更すると、それ以降変更せずに、そのプラグインのコードをコンパイルして実行することができます。
上述の org.eclipse.xerces プラグインへの依存性を持つ 2.1 のバイナリー・プラグインは、標準の Eclipse 3.0 構成で実行すると、前提条件をが欠落していることになります。その結果、このプラグインは活動化されません。
Eclipse 3.0 よりも前は、Eclipse はほとんどの場合、単一スレッドで実行していました。ほとんどの API メソッドおよび拡張ポイントは、UI スレッドか、UI スレッドをブロックした進行状況表示ダイアログから作成されたスレッドのいずれかで作動していました。ほとんどのプラグイン作成者は、スレッド・セーフティーに関しては、すべての UI アクティビティーを UI スレッドで発生させるようにすること以外、あまり気に懸けることはありませんでした。Eclipse 3.0 では一般に、より多くの並行処理を行うことができます。 多くの作業がバックグラウンド・スレッドで発生するようになり、それらは、UI スレッドも含めて、他のスレッドで並行して実行することができます。したがって、バックグラウンド・スレッドで実行されるコードを持つすべてのプラグインは、それぞれのコードのスレッド・セーフティーを意識しておく必要があります。
org.eclipse.core.runtime.jobs
API を使用して、バックグラウンドで作業を明示的に行うプラグインに加えて、いくつかのプラットフォーム API 機能および拡張ポイントでも、バックグラウンド・スレッドが使用されています。これらの機能にフックするプラグインは、そのコードがスレッド・セーフであることを保証する必要があります。以下の表は、Eclipse 3.0 において、そのコードの一部またはすべてをバックグラウンド・スレッドで実行する API および拡張ポイントを要約したものです。
拡張ポイントまたは API クラス |
注 |
org.eclipse.core.runtime.IRegistryChangeListener | Eclipse 3.0 で新規導入。バックグラウンドで実行します。 |
org.eclipse.core.resources.IResourceChangeListener | AUTO_BUILD イベントはバックグラウンドで実行するようになりました。 |
org.eclipse.core.resources.builders (ext. point) | 自動ビルドは、バックグラウンドで実行するようになりました。 |
org.eclipse.core.resources.ISaveParticipant | SNAPSHOT はバックグラウンドで実行するようになりました。 |
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (ext. point) | Eclipse 3.0 で新規導入。バックグラウンドで実行します。 |
org.eclipse.ui.decorators (ext. point) | すでに Eclipse 2.1 でバックグラウンドで実行しています。 |
org.eclipse.ui.startup (ext. point) | すでに Eclipse 2.1 でバックグラウンドで実行しています。 |
org.eclipse.team.core.org.eclipse.team.core.repository (ext. point) | 多くの命令がバックグラウンドで実行するようになりました。 |
org.eclipse.team.ui.synchronizeParticipants (ext. point) | Eclipse 3.0 で新規導入。バックグラウンドで実行します。 |
org.eclipse.debug.core.launchConfigurationTypes (ext. point) | バックグラウンドで実行するようになりました。 |
org.eclipse.jdt.core.IElementChangedListener | ElementChangedEvent.PRE_AUTO_BUILD はバックグラウンドで実行するようになりましたが、POST_RECONCILE はすでにバックグラウンドで実行しています。 |
コードをスレッド・セーフにするために、さまざまな戦略を利用できます。
本質的なソリューションとしては、すべての作業を UI スレッドで行う、という方法があります。
この場合、実行は必ず直列化されます。CPU 集中の処理を行わない UI プラグインの場合は、これが一般的なアプローチです。
これを行う場合は、Display.syncExec
には、本質的にデッドロックのリスクが伴うことを認識しておく必要があります。Display.asyncExec
の方が、一般的には安全です。
それは、この場合、コード実行時の制御の精度は低くなりますが、デッドロックのリスクは発生しないからです。
コードをスレッド・セーフにするための手法には、他に以下のものがあります。
org.eclipse.core.runtime.jobs.ILock
が含まれています。
汎用的なロックよりも ILock
が優れている点として、syncExec
を実行するときに、自動的に UI スレッドに移行すること、およびその実装に、デッドロックをログに記録し解決する、デッドロック検出サポートが組み込まれているという点を挙げることができます。Display.asyncExec
) です。これは、UI スレッドの中だけで処理されます。java.lang.String
および org.eclipse.core.runtime.IPath
などのデータ構造をスレッド・セーフにする場合に使用されます。不変オブジェクトの利点は、読み取りアクセスがきわめて高速になるという点です (ただし、変更時に余分な作業が発生します)。以下のメソッドは、org.eclipse.ui.IWorkbenchPage インターフェースから削除されました。 IWorkbenchPage は汎用のワークベンチで宣言されていますが、これらのメソッドは本来リソース固有のものです。
その代わりに、IWorkbenchPage.openEditor メソッドのクライアントが、(org.eclipse.ui.ide プラグイン内の) org.eclipse.ui.ide.IDE クラスで宣言されている、これらに対応するパブリックな静的メソッドを呼び出す必要があります。
これらの IWorkbenchPage.openSystemEditor(IFile) メソッドのクライアントは、新規の FileEditorInput(IFile) を使用して IFile を IEditorInput に変換し、次に、openEditor(IEditorInput,String) メソッドを呼び出す必要があります。すなわち、page.openSystemEditor(file) を page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID) として書き換えることを意味します。注: エディター ID IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID を使用しているクライアントは、org.eclipse.ui.IPathEditorInput を実装しているエディター入力を渡す必要があります (これは FileEditorInput が行います)。
注: これは、Eclipse 3.0 による 2.1 のバイナリー・プラグインの実行方法には影響しない非互換性の 1 つです。Eclipse 3.0 には、バイナリー・ランタイム互換メカニズムが組み込まれています。このメカニズムによって、この API の変更にもかかわらず、削除された openEditor および openSystemEditor メソッドのいずれかを使用している既存の 2.1 プラグイン・バイナリーが、2.1 の場合と同じように作動し続けることができます。 (削除されたメソッドは、実質的には、org.eclipse.ui.workbench.compatibility フラグメントによって「追加されて元に戻る」ことになります。)以下のメソッドは、org.eclipse.ui.IEditorPart インターフェースから削除されました。IEditorPart は、汎用ワークベンチで宣言されていますが、このメソッドは本来リソース固有のものです。
その代わりに、このメソッドを呼び出しているクライアントで、エディター・パーツが (org.eclipse.ui.ide プラグイン内の) org.eclipse.ui.ide.IGotoMarker を実装しているか、またはそれを適用しているかをテストする必要があります。IDE クラスには、そのテストを行うために便利なメソッド IDE.gotoMarker(editor, marker); があります。
IMarker 情報に基づいてそれ自体を配置できるエディターを実装しているクライアントは、org.eclipse.ui.ide.IGotoMarker を実装しているか、それを適用している必要があります。IGotoMarker の唯一のメソッドが gotoMarker(IMarker) で、古い IEditorPart.gotoMarker(IMarker) とシグニチャーと仕様が同じなので、単に IGotoMarker をクラス定義の implements 文節に組み込むだけで、既存のエディターの実装がこの変更を適用することができます。
このメソッドを呼び出すコードを持つ 2.1 バイナリー・プラグインは、標準の Eclipse 3.0 構成で実行すると、クラス・リンク・エラー例外を受け取ります。
エディター・ランチャー・インターフェース org.eclipse.ui.IEditorLauncher は、外部エディターを提供するプラグインによって実装されます。以下のメソッドは、このインターフェースから除去されました。IEditorLauncher は、汎用ワークベンチで宣言されていますが、このメソッドは本来リソース固有のものです。
これは、次のメソッドに置き換えられました。
このメソッドを呼び出すコードを持つ 2.1 バイナリー・プラグインは、標準の Eclipse 3.0 構成で実行すると、クラス・リンク・エラー例外を受け取ります。
以下のメソッドは、org.eclipse.ui.IEditorRegistry インターフェースから除去されました。 IEditorRegistry は汎用のワークベンチで宣言されていますが、これらのメソッドは本来リソース固有のものです。
システム外部エディターおよびシステム In-Place エディターを表す新規の定数 (SYSTEM_EXTERNAL_EDITOR_ID および SYSTEM_INPLACE_EDITOR_ID) が導入されました。これら 2 つのエディターには、org.eclipse.ui.IPathEditorInput を実装しているか、またはそれに適合しているエディター入力が必要です。In-Place エディター記述子は、In-Place 編集をサポートしていない Eclipse 構成には存在しないことに注意してください。
以下のメソッドは、org.eclipse.ui.IWorkbench インターフェースから削除されました。 IWorkbench は、汎用ワークベンチで宣言されていますが、このメソッドは本来リソース固有のものです。
このメソッドを呼び出すコードを持つ 2.1 バイナリー・プラグインは、標準の Eclipse 3.0 構成で実行すると、例外を受け取ります。
org.eclipse.ui.texteditor.AbstractTextEditor が IFile に依存しないようにするために、org.eclipse.ui.texteditor.AbstractDocumentProvider では、ドキュメント・プロバイダー命令 (DocumentProviderOperation) とドキュメント・プロバイダー命令実行者 (IRunnableContext) という概念が導入されています。リセット、保管、または同期化を実行するよう要求されると、AbstractDocumentProvider がドキュメント・プロバイダー命令を作成し、その命令の実行者を使用して、それらの命令を実行します。実行可能なコンテキストは、getOperationRunner メソッドを介して、サブクラスによって提供することができます。以下に、クライアントが適合する必要のある変更点の要約を示します。
AbstractDocumentProvider のサブクラス org.eclipse.ui.editors.text.StorageDocumentProvider は、常に null を戻す getOperationRunner メソッドを実装しています。つまり、StorageDocumentProvider のサブクラスは、この変更による影響を受けない、ということを意味します。
StorageDocumentProvider のサブクラス org.eclipse.ui.editors.text.FileDocumentProvider は、WorkspaceModifyOperation 内で与えられている DocumentProviderOperations を実行するための IRunnableContext を戻す getOperationRunner メソッドを実装しています。FileDocumentProvider に対するその他の変更は、以下のとおりです。
org.eclipse.ui.texteditor.AbstractTextEditor に対する変更は、以下のとおりです。
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
AbstractTextEditor のサブクラス org.eclipse.ui.texteditor.StatusTextEditor は、述部メソッド isErrorStatus(IStatus) を備えています。 ある状況をエラーと見なす必要があるかどうかを決定するために、サブクラスでオーバーライドできます。
org.eclipse.ui.editors.text.AbstractDecoratedTextEditor に対する変更は、以下のとおりです。
ヘッドレス注釈のサポートの導入の一部として、Annotation に対して以下の変更が行われました。
org.eclipse.jface.text.source.Annotation org.eclipse.jface.text.source.AnnotationModel org.eclipse.jface.text.source.AnnotationModelEvent org.eclipse.jface.text.source.IAnnotationModel org.eclipse.jface.text.source.IAnnotationModelListener org.eclipse.jface.text.source.IAnnotationModelListenerExtension
Eclipse 3.0 には、新しく汎用コンソール・サポートが備わりました。汎用コンソールは、「ウィンドウ」>「ビューの表示」>「基本」>「コンソール」を選択して使用することができ、Eclipse のデバッグおよび Ant の統合で使用されます。
コンソールのビュー ID は、org.eclipse.debug.ui.ConsoleView から org.eclipse.ui.console.ConsoleView に変更されました。このような古いビューが存在しなくなったので、プログラマチックにコンソールを開く 2.1 のプラグインは、正常に作動しません。
3.0 では、メソッド org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) および installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) の戻りの型は、 リスナーが「無指定」を選択できるように、boolean から int に変更されました。3.0 よりも前のリリースでは、リスナーが選択できるのは、ブレークポイントにヒットしたときの「中断する」または「中断しない」か、ブレークポイントがインストールされようとしたときの「インストールする」または「インストールしない」だけでした。 3.0 では、リスナーは、これらの通知のいずれでもよいことを表す「無指定」も選択することができます。 これにより、クライアントは、関心のある状態でのみ決定的な選択を行うことができます。「ブレークポイントにヒット」通知の場合、いずれかのリスナーが「中断する」を選択するか、またはすべてのリスナーが「無指定」を選択した場合は、そのブレークポイントは中断し、少なくとも 1 つのリスナーが「中断しない」を選択し、かつどのリスナーも「中断する」を選択しなかった場合は、そのブレークポイントは中断しません。 同様に、「ブレークポイントをインストール中」通知の場合、いずれかのリスナーが「インストールする」を選択するか、またはすべてのリスナーが「無指定」を選択した場合には、ブレークポイントはインストールされ、少なくとも 1 つのリスナーが「インストールしない」を選択し、かつどのリスナーも「インストールする」を選択しない場合には、ブレークポイントはインストールされません。 一般的に、実装は、いずれか一方に対して確実な見解がある場合以外は、DONT_CARE を戻す必要があります。例えば、「中断する」を選択すると、他のすべてのリスナーの「中断しない」という選択は指定変更されてしまうことを念頭に置いておく必要があります。
IJavaBreakpointListener インターフェースは、Java コード内のブレークポイントを作成するか、ブレークポイントに反応するクライアントによって実装されます。JDT それ自体を越えるクライアントはほとんどないので、この変更で修正される問題 (バグ 37760) を報告したクライアントは保管してください。これは、IJavaBreakpointListener インターフェースを実装している既存のコードにとっては、重大な変更です。このコードは、3.0 でコンパイルして実行する前に、適切な int 型の値を戻すよう修正する必要があります。
3.0 よりも前は、SWT クラス org.eclipse.swt.dnd.Clipboard のメソッドは、UI スレッド以外のスレッドでの実行が暗黙のうちに許可されていました。クリップボードとのすべての相互作用が UI スレッドで行われることがオペレーティング・システムによって要求される GTK で、このミスのために失敗が発生しました。多くのアプリケーションは単一スレッド化されており、それらのテストのほとんどは Windows で受け取っていたために、このようなミスは以前は明らかになっていませんでした。 Clipboard API を継続可能でかつクロスプラットフォームにするために、3.0 ではすべての Clipboard API のメソッドの仕様と実装が変更され、UI スレッド以外のスレッドから呼び出された場合は、SWT 例外 (ERROR_THREAD_INVALID_ACCESS) がスローされるようになりました。 クリップボード・サービスは、一般的にはテキスト・エディターなどの Eclipse コンポーネントによって自動的に提供されています。 このような Eclipse コンポーネントによって、多くのクライアントは、この重大な変更の影響を受けずに済みます。 クリップボードを直接利用している既存のコードは、アクセスを UI スレッドにシフトするのが適切な場合は、Display.asyncExec または syncExec を使用して、API のメソッドが正しいスレッドで呼び出されるようにする必要があります。
3.0 では、SWT は、OS での作業が完了する前に、キー・ダウン・イベントを報告します。 これは、3.0 よりも前のものと比べてずっと早くなっています。 このような変更が行われたのは、どのウィジェットがキーの文字を処理する機会を得るよりも前に、キー・イベントをインターセプトする必要がある Eclipse で、キー・バインディングをサポートするためでした。 この変更の結果は、低レベルの org.eclipse.swt.SWT.KeyDown イベントを直接処理するコードに対しては、可視になっています。 例えば、テキスト・ウィジェットのリスナーがキー・ダウン・イベントを受け取ったとき、そのウィジェットの内容 (getText()) には、まだ入力されたばかりのキーは含まれていない (3.0 よりも前はこのようになっていました) ことを意味します。 現行キーを含むウィジェットからフルテキストを取得するには、低レベルの SWT.KeyDown イベントではなく、より高いレベルの SWT.Modify または SWT.Verify イベントを処理することをお勧めします。 すでにこのようにして処理を行っているコードは、この変更による影響は受けません。
3.0 よりも前は、SWT クラス org.eclipse.swt.widgets.Canvas またはそのサブクラスの 1 つ (カスタム・ウィジェットを含む) にフォーカスがある場合、Ctrl+Tab、Shift+Tab、Ctrl+PgUp、または Ctrl+PgDn を入力すると、 キー・イベントを報告せずに、次/前のウィジェットへのトラバーサルが自動的にトリガーされていました。 この振る舞いは指定されておらず、キャンバスが入力されるすべてのキーを見るという規則に反しています。 トラバーサルを処理する適切な方法は、トラバース・リスナーを登録することです。3.0 で Eclipse のキー・バインディングを適切にサポートするために、デフォルトの振る舞いが変更され、キャンバスはトラバースではなく、Ctrl+Tab、Shift+Tab、Ctrl+PgUp、および Ctrl+PgDn キー・イベントを見るようになりました。 キャンバスそのものを使用している場合、またはキャンバスのサブクラスを定義している場合は、必ずトラバース・リスナーを登録するようにしてください。
SWT クラス org.eclipse.swt.widgets.Table および Tree でマウスにより項目を選択すると、すべてのオペレーティング環境において、MouseDown-Selection-MouseUp というイベント・シーケンスが均一に生成されます。 同様に、キーボードで選択を行うと、すべてのオペレーティング環境において、KeyDown-Selection-KeyUp というイベント・シーケンスが均一に生成されます。3.0 よりも前の Motif および Photon では、それ以外のオペレーティング・システムとは異なり、イベントの順序は均一ではなく、常に選択イベントが最初に報告されていました。 つまり、Selection-MouseDown-MouseUp、または Selection-KeyDown-KeyUp の順でした。3.0 では、Motif および Photon でのイベント順序は、それ以外のオペレーティング・システムに一致するように変更されています。{Windows、GTK} および {Motif、Photon} で正常に機能していた既存のコードは、影響を受ける可能性はほとんどありません。 ただし、コードをチェックして、無効なイベント順序に依存していないことを確認してください。
org.eclipse.core.runtime.IStatus
には、新しい重大度定数 IStatus.CANCEL
が加えられました。これは、キャンセルを示すために使用することができます。起こりうる重大度が IStatus.OK
、
INFO
、WARNING
、および ERROR
に制限されている重大度セットに依存している IStatus.getSeverity()
の呼び出し元は、この定数追加により影響を受けます。
getSeverity
の呼び出し元は、そのコードを更新して、新規の重大度を組み込むようにする必要があります。
Eclipse 3.0 では、ワークスペースの自動ビルドは、バックグラウンド・スレッドで行われるようになりました。これにより、API 規約を org.eclipse.core.resources.IResourceChangeEvent
に変更する必要があります。IResourceChangeEvent
の規約はこれまでは、すべてのワークスペース変更に対して、以下のイベントの配列を保証していました。
PRE_DELETE
または PRE_CLOSE
イベント通知 (該当する場合)PRE_AUTO_BUILD
イベント通知POST_AUTO_BUILD
イベント通知POST_CHANGE
イベント通知現在は、自動ビルドはバックグラウンドで実行され、AUTO_BUILD
イベントと POST_CHANGE
イベントの間の一時的な関係は保証されなくなっています。Eclipse 3.0 では、上の構造のステップ 3 〜 5 は、操作から除外されています。その結果、次のようになります。
PRE_DELETE
または PRE_CLOSE
イベント通知 (該当する場合)POST_CHANGE
イベント通知プラットフォームは、定期的にバックグラウンドでワークスペース・ビルド操作を実行します。これは、自動ビルドがオンまたはオフのどちらになっているかには関係なく行われることに注意してください。このビルドがいつ行われるのかについての正確なタイミングは、指定されません。ビルド操作の構成は、次のようになります。
PRE_BUILD
イベント通知 (PRE_BUILD
は、PRE_AUTO_BUILD
の新しい名前です)POST_BUILD
イベント通知 (POST_BUILD
は POST_AUTO_BUILD
の新しい名前です)POST_CHANGE
イベント通知自動ビルド・リスナーが受け取る差分の参照点は、変更後リスナーとは異なります。ビルド・リスナーは、最後のビルド操作の終了以降に行われたすべての変更の通知を受け取ります。変更後リスナーは、最後の変更後通知以降に行われたすべての変更を記述した差分を受け取ります。この新規の構造は、Eclipse 1.0 から一貫している次の 3 つのリソース変更リスナーの特性を保持しています。
POST_CHANGE
リスナーは、リソースの登録中に発生するすべてのリソース変更の通知を受け取ります。これには、ビルダーが行った変更、およびその他のリスナーが行った変更が含まれます。PRE_AUTO_BUILD
リスナーは、ビルダーおよびリソース変更リスナーが行った変更以外のすべてのリソース変更通知を受け取ります。POST_AUTO_BUILD
リスナーは、他の POST_AUTO_BUILD
リスナーが行った変更以外のすべてのリソース変更通知を受け取ります。
ただし、このアプローチにはいくつかの重要な相違点があります。Eclipse 3.0 よりも前は、自動ビルド・リスナーは、常に POST_CHANGE
リスナーよりも前に呼び出されていました。この理由から、自動ビルド・リスナーが受け取る差分は、常に POST_CHANGE
リスナーが受け取る差分のサブセットでした。
この関係は、現在では基本的に逆転しています。自動ビルド・リスナーは、最後のバックグラウンド・ビルドの終了以降に POST_CHANGE
リスナーに提供されるすべての差分のスーパーセットである差分を受け取ります。以前と同様、自動ビルド・リスナーは、ワークスペースを変更することを許可されますが、変更後リスナーは許可されません。
ワークスペース変更操作を完了すると、その AUTO_BUILD
イベント・リスナーに通知される、ということは当てはまらなくなります。
リソース変更リスナーを IWorkspace.addResourceChangeListener(IResourceChangeListener)
に登録するクライアント・コードがこの変更によって影響を受ける可能性はないでしょう。
それは、AUTO_BUILD
イベントはこれらのリスナーに報告されることがなかったからです。
ただし、IWorkspace.addResourceChangeListener(IResourceChangeListener,int)
を使用し、AUTO_BUILD
イベントを含むイベント・マスクを指定しているクライアントは、自動ビルド・リスナーを実行する時点、または実行するスレッドに関して前提を設けている場合は、この変更によって動作しなくなる可能性があります。
例えば、自動ビルド・リスナーがドメイン・モデルを更新して、ワークスペースへの変更を反映しようとしている場合は、ワークスペース変更操作が戻ったときに、この更新が行われない可能性があります。
このようにして影響を受ける可能性があるのは、UI レベルのコードだけであることを十分に注意してください。API を介して呼び出されるコア・レベルのコードは、IWorkspaceRunnable
のスコープ内で呼び出される可能性があるので、いつリソース変更リスナーが呼び出されるかは明確ではありません。この破綻に対する推奨修正は、操作の完了前に通知を発生させる必要がある場合には、ビルド・リスナーの代わりに POST_CHANGE
を使用することです。
IWorkspaceRunnable
の動的スコープ中に発生するすべてのリソース変更が、単一の通知としてバッチ処理される保証はありません。
このメカニズムは、不必要なビルドおよび通知を回避するために、従来どおり変更のバッチ処理に使用することができますが、プラットフォームが操作中に、通知を実行することを決定できるようになりました。
この API 規約の変更が、既存のクライアントにとって重大な変更になる可能性はありません。
これは、プラットフォームが、長時間にわたる操作中に、定期的に IWorkspace.checkpoint
を呼び出すことを決定する場合も同じです。
この変更の理由は、複数のスレッドでワークスペースを並行して変更することができるようになったからです。1 つのスレッドがワークスペースの変更を終了する場合は、他の操作がまだ完了していなくても、応答に関する問題を防ぐために通知が必要となります。
この変更により、操作が完了する前に、ユーザーはリソースのセットに対する作業を開始することもできます。
例えば、まだチェックアウト中のプロセスにあるプロジェクトにおいて、ファイルのブラウズを開始することができます。
新規のメソッド IWorkspace.run(IWorkspaceRunnable,
ISchedulingRule, int, IProgressMonitor)
は、オプションのフラグ AVOID_UPDATE
を持っています。
操作中にこのフラグをプラットフォームに対するヒントとして使用して、定期的な更新が必要かどうかを指定することができます。
影響を受けるもの: org.eclipse.core.runtime.urlHandlers
拡張ポイントへの拡張を提供するプラグイン。
説明: org.eclipse.core.runtime.urlHandlers
拡張ポイントに対する規約は、OSGi が提供する URL ストリーム・ハンドラー・サービスを使用するよう変更されました。OSGi サポートは、Eclipse 2.1 の場合よりも優れており、動的ハンドラーを正しく処理します。基本的な Java URL ハンドラーのメカニズムに関するさまざまな設計上の問題により、OSGi ハンドラー・サービスに登録されている URLStreamHandlers は、org.osgi.service.url.URLStreamHandlerService
を実装する必要があります。
必要なアクション: 以前は、ハンドラー・クラスは java.net.URLStreamHandler
を実装し、urlHandlers 拡張ポイントを拡張する必要がありました。この拡張ポイントはサポートされなくなり、org.osgi.service.url.URLStreamHandlerService
インターフェースを実装するようハンドラーを更新する必要があります。OSGi フレームワークは、普通にサブクラス化してこの役割を果たすことのできる抽象基本クラス (org.osgi.service.url.AbstractURLStreamHandlerService
) を提供しています。
拡張ポイントを使用してハンドラーを登録する代わりに、プラグインがそのハンドラーをサービスとして登録し、ハンドラーの登録を行う必要があります。以下に例を示します。
Hashtable properties = new Hashtable(1); properties.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] {MyHandler.PROTOCOL}); String serviceClass = URLStreamHandlerService.class.getName(); context.registerService(serviceClass, new MyHandler(), properties);
影響を受けるもの: 与えられているパッケージを提供し、他のプラグインによっても提供されるプラグイン。この変更によって影響を受けるプラグインの数は非常に限られていますが、実際には、それら影響を受けるプラグインの一部にとっても利点があります (以下を参照)。
説明: Eclipse 2.x では、クラス・ローダーは、次の順にクラスを検索します。(1) 親のクラス・ローダー (実際にはこれは Java ブート・クラス・ローダーです)、(2) 次にそれ自体のクラスパスの内容、 そして最後に (3) 宣言されている順にそのすべての前提条件、という順に問い合わせを行います。OSGi は、このモデルに対する最適化を提供しています。 このアプローチでは、クラス・ローダーは、(1) 親のクラス・ローダー (この場合も、実際には Java ブート・クラス・ローダー)、次に (2a) 照会されるパッケージ内のクラスを提供することが分かっている単一の前提条件か、 または (2b) 目的のクラスのそれ自体のクラスパス項目のうちのいずれか、の順に問い合わせを行います。
クラス・ローダーは、そのインポートされ、要求されているパッケージに基づいて、それ自体またはその前提条件のいずれに問い合わせるかを決定します。この情報は、従来のプラグインの場合はプラグイン・コンテンツから推測され、明示的な OSGi バンドル・マニフェストを持つプラグインの場合は、直接指定されます。いずれの場合も、どのクラス・ローダーがどのパッケージのクラスを提供するのかは先験的に 分かります。これにより、パフォーマンスが向上し、複数の前提条件が同じクラスを提供するという煩わしい問題を解決することができます。
例として、Xerces と Xalan の場合を考えてみましょう。これらは、どちらも、org.xml パッケージのさまざまなクラスを含んでいます。最初のアプローチを使用すると、Xerces プラグインは、これらのクラスの、そのプラグインのコピーを見ることになります。これに対して、Xalan プラグインは、これらのクラスのコピーを見ることになります。これらのプラグインは通信する必要があるので、ClassCastExceptions が発生します。2 番目のアプローチを使用すると、これら 2 つのプラグインの内の一方だけが重複するクラスを提供し、両方のプラグインが同じコピーを見ることになります。
必要なアクション: 必要なアクションは、ユース・ケースの詳細によって異なります。影響を受ける開発者は、自分のクラスパスを検討し、発生する可能性のある競合を解決する必要があります。
影響を受けるもの: 常に、それぞれのクラス・ローダーの保護ドメインが設定されることを想定しているプラグイン。
説明: Eclipse 2.1 プラグイン・クラス・ローダーは java.security.SecureClassloaders であり、そのようなものとして常に保護ドメインを設定していました。Eclipse 3.0 では、クラス・ローダーは SecureClassloader を拡張しておらず、Java セキュリティーがオンになっている場合 (通常はこのようなことはありません) に限り、保護ドメインを設定します。
必要なアクション: 必要なアクションは、プラグインが保護ドメインを使用するシナリオによって異なります。
影響を受けるもの: org.eclipse.core.runtime.IPlugin* 型のオブジェクトを org.eclipse.core.runtime.model.Plugin*Model にキャストしているプラグイン。これらのインターフェースとモデル・クラス間の関係は、Eclipse 2.1 API では指定されていませんが、2.1 の実装でこの関係に依存しているプラグインの例を見つけたので、この変更に注意を促しておきます。
説明: Eclipse API は、プラグインおよびプラグイン・レジストリーに関連する一連のインターフェース (例えば、IPluginDescriptor
) および
いわゆる「モデル」クラス (例えば、PluginDescriptorModel
) を備えています。Eclipse 2.1 の実装では、偶然に、モデル・クラスが関連するインターフェースを実装しています。
新規の OSGi ベースのランタイムでは、プラグイン・レジストリーをかなり修正し、クラス・ロードとプラグインの前提条件となる側面、および拡張と拡張ポイントの側面を分離できるようにしています。したがって、Eclipse 3.0 ランタイムは、2.1 に存在していた実装の関係を維持することができません。
必要なアクション: この 非 API 関係に依存しているプラグインを、そのユース・ケースに従って、コードに手を加える必要があります。この詳細については、この資料の推奨する変更のセクションおよび関連するクラスおよびメソッドの javadoc に記載しています。
影響を受けるもの: org.eclipse.core.runtime.ILibrary
を使用しているプラグイン。
説明: 新規のランタイムは、Eclipse とは異なる、互換性のない形式でクラスパス項目を保守しています。その結果、互換レイヤーは基本となる OSGi 構造を ILibrary オブジェクトとして正しくモデル化することができません。ランタイムの互換性のサポートでは、ILibrary オブジェクトは作成されますが、ライブラリーのパスを除くすべてに対してデフォルト値を想定する必要があります。
必要なアクション: ILibrary のユーザーは、適切な Bundle (Bundle.getHeaders()
を参照) から、望ましいヘッダー値 (例えば、Bundle-Classpath
) にアクセスすること、および ManifestElement
ヘルパー・クラスを使用して項目を解釈することを考える必要があります。
詳細は、このクラスの Javadoc を参照してください。
影響を受けるもの: それぞれのインストール構造、ロケーション、およびローカル・ファイル・システムのレイアウトに関して前提事項を設けているプラグイン。
説明 IPluginDescriptor.getInstallURL()
などのメソッドは、特定の形式の URL を戻します。
その形式は仕様では指定されていないにも関わらず、さまざまなプラグインは、現在のインプリメンテーションに基づいて前提事項を設けています。
例えば、プラグインは、file:
という形式の URL を取得し、URL.getFile() を使用してその結果に対して java.io.File
操作を実行することを想定することもできます。
今までのところ、これは正常に機能しているアプローチですが、かなり脆弱なアプローチです。
例えば、プラグインが Web サーバーにインストールされている場合は、http:
という形式の URL が戻される可能性があります。
新規の Eclipse 3.0 ランタイムはより柔軟であり、実行構成にはより多くの可能性が開かれています (例えば、複数のディレクトリーに展開するのではなく、プラグイン全体を JAR で保守する)。
すなわち、新規の OSGi ベースのランタイムは、それが実際に 2.1 API に違反していない間は、現行のプラグインに設けられている前提事項が無効である場合が多くあることを明らかにしているのです。
必要なアクション: プラグインを作成する場合には、アクセスする必要のある情報を getResource()
を介して取得できること (そして、それがクラスパス上にあること) を確認するか、または関連する API (例えば、Bundle.getEntry(String)
) を使用して、プラグインの内容にアクセスする必要があります。
影響を受けるもの: クラス org.eclipse.core.boot.BootLoader
からいくつかのメソッドを呼び出す、プラグイン以外のコード。
説明: 静的なメソッド BootLoader.startup()、shutdown()、および run() は、OSGi フレームワークの一部である org.eclipse.core.runtime.adaptor.EclipseStarter に移動されました。 この API は、startup.jar の main() と OSGi フレームワーク/Eclipse ランタイムの間のインターフェースです。ランタイムを再構築するにあたって、これらのメソッドを BootLoader に留めておくことはできませんでした。古い BootLoader クラスは、現在は実行時の互換性レイヤーにあり、使用すべきではないので、移動されたメソッドは何も行わないようになっています。
ランタイムは各アプリケーションの獲得をサポートできなくなったため、古い BootLoader.getRunnable() の代わりになるものはありません。むしろ、ユーザーは、プラットフォームの開始時に、重要なアプリケーションを示す必要があります。
必要なアクション: 一般にこの API はほとんど使用されません (Eclipse プラグインからは使用できません)。まれに使用することがある場合は、EclipseStarter の対応するメソッドを使用するよう、コードを修正する必要があります。
影響を受けるもの: すべてのプラグイン。
説明: Eclipse 2.1 では、build.properties のプラグインの bin.includes 行には、plugin.xml ファイル内のそれぞれのライブラリー宣言からの JAR のリストが含まれている必要はありませんでした。これらの JAR は自由に追加されました。Eclipse 3.0 では、build.properties の bin.includes セクション内のファイルのリストは、完全なリストで、プラグイン開発者が、ビルド時またはエクスポート時にそれぞれのプラグインに組み込もうとしているすべてのファイルが含まれている必要があります。
必要なアクション: build.properties ファイルの bin.includes 行には、plugin.xml ファイルにリストされているすべての JAR が含まれていることを確認してください。
影響を受けるもの: 変更されたランタイム API からの要素を含んでいる API を公開しているプラグイン。
説明: 各種プラグインは、ランタイム API からの要素を組み込んでいる API を公開しています。ここで概説している Eclipse 3.0 ランタイムに対する変更に伴い、クライアントのプラグインは、それらの API におけるランタイム API の使用を再評価する必要があります。
必要なアクション: ほとんどの Eclipse ランタイム API は変更されていないので、このシナリオはかなりまれなものです。シナリオに応じて、クライアントはそれぞれの API を変更することも、互換性レイヤーに依存し続けることもできます。
影響を受けるもの: org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) を使用しているプラグイン。
説明: org.eclipse.core.runtime.Platform.parsePlugins(..., Factory)
メソッドは移動されました。引数 Factory に関連付けられている API は、org.eclipse.core.runtime プラグインから、(ランタイム・プラグインに依存する) org.eclipse.core.runtime.compatibility プラグインに移動されました。その結果、構文解析メソッドも同様に移動されました。
必要なアクション: このメソッドを使用する場合は、org.eclipse.core.runtime.model.PluginRegistryModel
クラスの同じメソッドを使用する必要があります。
影響を受けるもの: それぞれのクラスパスでコードを指定しているけれども、そのコードを提供していないプラグイン (すなわち、JAR はフラグメント、例えば org.eclipse.swt プラグインによって提供される)。
説明: 新規のランタイムは、plug.xml ファイルをバックグラウンドで manifest.mf ファイルに変換する必要があります。これは、単純な機械的変換、およびこのプラグインがリストし、提供している jar の解析を介して行われます。プラグインがそのクラスパスで jar を指定していても、その jar を提供していない場合は、分析するコードがないので、プラグイン・コンバーターは正しい manifest.mf を生成できません。
必要なアクション: そのようなプラグインのプロバイダーは、プラグインそれ自体で適切な jar を提供するよう変更するか、プラグイン用の META-INF/MANIFEST.MF ファイルを作成するか、保守する必要があります。一般に、これを行うには、PDE を使用して初期のマニフェストを取得し、次に適切な Provide-Package ヘッダーに追加します。
影響を受けるもの: ランタイム関連の jar およびクラス・ディレクトリーを含むクラスパスを定義しているスクリプト (たとえば、Ant build.xml ファイル)。
説明: 新規のランタイムには、多くの新規のプラグインおよび jar が含まれています。それらを導入することになったのは、ランタイムを構成可能な部分にリファクタリングしたからです。ほとんどのランタイム状況では、これらの変更は透過的です。
ただし、現在 org.eclipse.core.runtime
に対してコードをコンパイルするカスタムの build.xml (または類似の) スクリプトがある場合は、それらのスクリプトを更新して、正常に動作するようにする必要があります。
典型的なスクリプトは、以下のように、org.eclipse.core.runtime
プラグインを参照しているクラスパス・エントリーを <javac> タスクに含んでいます。
../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar
ランタイム・プラグインには、オリジナルのほとんどのランタイム・コードが引き続き含まれています。
ただし、互換性の目的だけで存在しているランタイムのさまざまな部分は、互換性プラグイン (org.eclispe.core.runtime.compatibility
) に含まれています。
新規のランタイム・コードのほとんどは、プラグインのコレクション (org.eclipse.osgi.*
) に含まれています。
必要なアクション: コンパイル・エラーが発生しないようにするために、開発者は必要に応じて以下の項目を追加する必要があります。以下には、提供されている jar の完全セットをリストしていますが、一般的な使用には、コンパイル時にクラスパス上のサブセットだけが必要になります。従来どおり、/bin ディレクトリーを組み込むかどうかは自由です。ここでは、プラグインを提供することにより、項目は論理グループで与えられています。
さらに、特殊な場合には、以下の jar が必要になることもあります。
そのようなスクリプトの更新中の適当な機会に、org.eclipse.core.boot
への参照のクリーンアップ (すなわち、除去) も行ってください。
このプラグインは廃止されており、コードが含まれていません。項目をクラスパス上に残しておくことはできますが、有益ではないため、除去してください。以下を除去してください。
../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar
影響を受けるもの: eclipse.buildScript タスクを使用しているスクリプト (例えば、Ant build.xml ファイル)。
説明: PDE ビルドで、プラグイン・ビルド・スクリプトの生成を制御するための eclipse.buildScript タスクに新規のプロパティーが導入されました。 これは、新規の OSGi ベースのランタイムの導入に伴って行われたものです。
必要なアクション: Eclipse 3.0 を使用して 2.1 ベースの製品をビルドしたい場合は、eclipse.buildScript にプロパティー「buildingOSGi」を導入し、それを false に設定してください。 以下に例を示します。
<eclipse.buildScript ... buildingOSGi="false"/>
影響を受けるもの: eclipse.buildScript タスクを使用しているスクリプト (例えば、Ant build.xml ファイル)。
説明: PDE ビルドで、プラグイン・ビルド・スクリプトの生成を制御するための eclipse.buildScript タスクに新規のプロパティーが導入されました。 これは、新規の OSGi ベースのランタイムの導入に伴って行われたものです。
必要なアクション: Eclipse 3.0 を使用して 2.1 ベースの製品をビルドしたい場合は、eclipse.buildScript にプロパティー「buildingOSGi」を導入し、それを false に設定してください。 以下に例を示します。
<eclipse.buildScript ... buildingOSGi="false"/>
影響を受けるもの: eclipse.buildScript タスクを使用しているスクリプト (例えば、Ant build.xml ファイル)。
説明: PDE ビルドでは、eclipse を自動ビルド・スタイルでビルドしやすくするために、eclipse.fetch タスクの振る舞いが変更されました。要素スタイルは、一度に 1 つの項目しかサポートしなくなり、scriptName は常に無視されます。
必要なアクション: eclipse.fetch 呼び出しの「element」タグに項目のリストがある場合は、それらを eclipse.fetch へのいくつかの呼び出しに分散してください。 scriptName の設定に使用する場合は、生成されたフェッチ・スクリプトは常に「fetch_{elementId}」という名前になっていることに注意してください。 以下に例を示します。
<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>
上記の URL は、次のようになります。
<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../> <eclipse.fetch elements="feature@org.eclipse.platform" .../>
install.ini ファイルは、組み込まれなくなりました。その代わりに、新規の config.ini ファイルが configuration サブディレクトリーに含まれています。install.ini ファイルを使用して 1 次フィーチャー (例えば、ブランド情報の提供) を指定する製品では、その代わりに、config.ini ファイルに変更を加える必要があります。新規のファイル名以外にも、キーの名前が変更されています。
2.1 の feature.default.id キーの値は、新規の eclipse.product キーの値として設定する必要があります。eclipse.application の値は、「org.eclipse.ui.ide.workbench」に設定する必要があります。
最後に、2.1 では、スプラッシュ・イメージのイメージは、常にブランド・プラグインのディレクトリー内の splash.bmp でした。3.0 では、スプラッシュ・イメージのロケーションは、config.ini ファイル内の osgi.splashPath キーによって明示的に与えられています。