プラットフォーム・コアが実行中でリソース・プラグインがアクティブの場合には、 ワークスペースは、インスタンス IWorkspace によって表されます。このインスタンスは、それが含むリソースにアクセスするプロトコルを提供します。IWorkspace インスタンスは、 ローカル・ファイル・システム内の関連付けられたファイルおよびディレクトリーの集合を表します。ユーザーは、 ワークスペースに org.eclipse.core.resources 内のリソース・プラグイン・クラスからアクセスできます。
ResourcesPlugin.getWorkspace();
リソース・プラグインが実行中でない場合には、ワークスペースは、単にローカル・ファイル・システム内に存在するだけで、 ユーザーによって標準ファイルをベースにするツールで表示または操作されます。 リソース・プラグイン API の説明の際に、ディスク上でワークスペースがどのように表されているかを説明します。
プラットフォーム SDK のインストール時に、ユーザーが選択したディレクトリーにファイルが UNZIP されています。 このディレクトリーは、プラットフォーム・ルート・ディレクトリーと呼ばれています。 特に、このディレクトリーは、プラグイン・ディレクトリーを含むディレクトリーです。プラットフォーム・ルート・ディレクトリーの中に、 プラットフォームによって作成および操作されるリソースの保持に使用するワークスペース・ディレクトリーがあります。 ユーザーのワークスペース・ディレクトリーには、 ワークスペースに存在するそれぞれのプロジェクトごとに別々のサブディレクトリーがあります。これらのサブディレクトリーの中には、各プロジェクトが含むフォルダーおよびファイルがあります。
本書の例における SDK が c:\MySDK にインストールされている場合には、c:\MySDK\workspace ディレクトリーの中に、 ワークスペースのプロジェクト、MyWeb および MyServlet から名前を取ったサブディレクトリーがあります。これらのサブディレクトリーは、プロジェクトのコンテンツ・ディレクトリーと呼ばれています。 コンテンツ・ディレクトリーは、ユーザーがプロジェクトを作成する時にプラットフォームによって作成されます。
それぞれのディレクトリーの中には、プロジェクト内のファイルおよびフォルダーがあります。 これらのファイルおよびフォルダーは、ワークスペースのリソース・ツリー内とまったく同じ方法でレイアウトされています。すべてのファイル名は同じであり、ファイルのコンテンツは、 ファイル・システムまたはワークスペースのどちらからアクセスしても同じです。 これは、例外的なことではありあません。
C:\MySDK\workspace (ワークスペース・ルート)
.metadata\ (プラットフォーム・メタデータ・ディレクトリー)
MyWeb\ (MyWeb のプロジェクトのコンテンツ・ディレクトリー)
index.html
images\
logo.gif
MyServlet\ (MyServlet のプロジェクトのコンテンツ・ディレクトリー)
src\
main.java
bin\
main.class
main$$1.class
プラットフォームには、プラットフォームの内部情報を保持するための特別な .metadata ディレクトリーがあります。 ワークスペースの .metadata ディレクトリーは、"ブラック・ボックス"として扱われます。 プロジェクトの参照またはリソースのプロパティーなどのワークスペース構造に関する重要な情報は、 ワークスペースのメタデータ部分に保管され、 プラットフォームの API を使用するツールのみでアクセスする必要があります。 これらのファイルは汎用ファイル・システム API を使用して編集または操作できません。
.metadata ディレクトリーの他に、 ワークスペース・ディレクトリー内のフォルダーおよびファイルは、他のツールからも都合よく使用されます。 ファイルおよびフォルダーは、テキスト・エディターおよびファイル・システム・ユーティリティーなどの、非統合ツールによって操作されることがあります。 唯一の問題は、ワークベンチおよび外部の両方でこれらのファイルを編集する場合に注意が必要なことだけです。 (このことは、 ユーザーが 2 つの独立したスタンドアロン・ツールを使用して 1 つのファイルを編集するときと同じです。) ワークベンチは、 ファイル・システム内の実際の状態と、リソースのワークスペース・ビューを調和させるための refresh 操作を提供します。
リソース API によって、ユーザーは、このリソース・ツリーをコードで操作できます。以下は、リソース API を簡単に理解するためのいくつかの断片的なコードです。 リソース API は、org.eclipse.core.resources 内の一連のインターフェースで定義されています。IProject、 IFolder、および IFile などのすべてのリソース型に対して、 インターフェースが存在します。広範囲な共通プロトコルは、 IResource に定義されます。org.eclipse.core.runtime インターフェース IPath も使用します。 このインターフェースは、リソースまたはファイル・システム・パスなどのセグメント化されたパスを表しています。
リソース操作は、java.io.File を使用するファイル操作に非常に似ています。 API はハンドルに基づいています。 getProject または getFolder のような API を使用する場合には、 リソースへのハンドルがユーザーに戻されます。 ユーザーがハンドルを使用して何らかの操作をするまでは、 そのリソース自体が存在するという保証または必要性はありません。 リソースが存在すると考えられる場合には、exists() プロトコルを使用して存在を確認できます。
プラグインからワークスペースをナビゲートするには、最初に IWorkspaceRoot を取得する必要があります。 これはワークスペースの最上位のリソース階層です。
IWorkspaceRoot myWorkspaceRoot = ResourcesPlugin.getWorkspace().getRoot();
ワークスペース・ルートを一度取得すると、ワークスペース内のプロジェクトをアクセスできます。
IProject myWebProject = myWorkspaceRoot.getProject("MyWeb");
// open if necessary
if (myWebProject.exists() && !myWebProject.isOpen())
myWebProject.open(null);
プロジェクトを操作するには、そのプロジェクトをオープンする必要があります。プロジェクトのオープンは、 ディスクからプロジェクトの構造を読み取り、 プロジェクトのリソース・ツリーのメモリー内のオブジェクト表記を作成します。 プロジェクトのオープンは明示的な操作です。 これは、それぞれのオープン・プロジェクトがリソース・ツリーを内部に表示するためにメモリーを消費し、 オープン・プロジェクトが、場合によっては非常に長いものとなる各種のリソース・ライフ・サイクル・イベント (ビルドなど) に参加するためです。 一般的に、クローズされたプロジェクトはアクセスできず、 リソースがまだそのファイル・システムに存在していても、空で表示されます。
これらリソースの例の多くは、リソースを操作する時に NULL パラメーターを渡すことに注意してください。 ほとんどのリソース操作は、進行報告およびユーザー・キャンセルを確実に行うために複雑になる可能性があります。 ユーザーのコードにユーザー・インターフェースが含まれている場合、 通常 IProgressMonitor を渡します。 このモニターによって、リソース・プラグインはリソースの操作時に進行を報告し、 ユーザーは必要であれば操作をキャンセルできます。 ここでは単に、進行をモニターしないことを示す NULL を渡します。
一度オープン・オブジェクトができると、そのオブジェクトのフォルダーおよびファイルにアクセスし、追加のフォルダーおよびファイルを作成できます。 以下の例では、ユーザーのワークスペース外にある外部ファイルのコンテンツからファイル・リソースを作成します。
IFolder imagesFolder = myWebProject.getFolder("images");
if (imagesFolder.exists()) {
// create a new file
IFile newLogo = imagesFolder.getFile("newLogo.gif");
FileInputStream fileStream = new FileInputStream(
"c:/MyOtherData/newLogo.gif");
newLogo.create(fileStream, false, null);
fileStream.close();
}
上記の例では、最初の行がイメージ・フォルダーへのハンドルを取得します。 フォルダーの作業を行う前に、そのフォルダーの存在を検査する必要があります。 同様に、newLogo ファイルを取得する場合、 最終行でそのファイルを作成するまで、ハンドルは実際のファイルを表しません。 この例では、ファイルの作成は、ファイルに logo.gif の内容を取り込むことで行います。
以下のコードの断片は、直前の例と同様です。ただし、newLogo ファイルを、 その内容から新規に作成するのではなく、オリジナルのロゴからコピーします。
IFile logo = imagesFolder.getFile("logo.gif");
if (logo.exists()) {
IPath newLogoPath = new Path("newLogo.gif");
logo.copy(newLogoPath,
false, null);
IFile newLogo = imagesFolder.getFile("newLogo.gif");
...
}
最後に、他のイメージ・フォルダーを作成し、新規に作成したファイルをそのフォルダーに移動します。移動に伴って、そのファイルを名前変更します。
...
IFolder newImagesFolder = myWebProject.getFolder("newimages");
newImagesFolder.create(false, true, null);
IPath renamedPath = newImagesFolder.getFullPath().append("renamedLogo.gif");
newLogo.move(renamedPath, false, null);
IFile renamedLogo = newImagesFolder.getFile("renamedLogo.gif");
リソース API メソッドの多くは、 ローカル・ファイル・システム内の対応するファイルと同期していないリソースを更新するかどうかを指定する、force ブール値フラグを含んでいます。 詳しくは、IResource を参照してください。
サンプル・リソース・ツリーでは、すべてのプロジェクトのコンテンツ・ディレクトリーが、 プラットフォームのルート・ディレクトリーの下にある workspace ディレクトリーに存在することを前提にしていました (C:\MySDK\workspace)。 これはプロジェクトのデフォルト構成です。 ただし、 プロジェクトのコンテンツ・ディレクトリーは、おそらく異なるディスク・ドライブ上に存在する、 ファイル・システム内の任意のディレクトリーに再マップできます。
他のプロジェクトとは独立したプロジェクトのロケーションをマップする機能によって、 ユーザーは、そのプロジェクトおよびプロジェクト・チームにとって適切な場所に、プロジェクトのコンテンツを保管できます。 プロジェクトのコンテンツ・ディレクトリーは、"オープン状態"として扱う必要があります。 つまりユーザーは、ワークベンチおよびプラグインを使用して、またはファイル・システム・ベースのツールおよびエディターを直接使用して、リソースの作成、変更、および削除が行えます。
リソース・パス名は、完全ファイル・システム・パスではありません。リソース・パスは、 常にプロジェクトのロケーション (通常は workspace ディレクトリー) に基づいているわけではありません。 リソースへの完全ファイル・システム・パスを取得するには、IResource.getLocation() を使用してそのリソースのロケーションを照会する必要があります。
ユーザーは、getLocation() を使用してロケーションを照会することで、 特定のリソースのファイル・システム・ロケーションを判別できます。 ただし、そのロケーションを変更するために、IProjectDescription.setLocation を使用することはできません。 これは、このメソッドがデータ構造の単なる setter でしかないためです。
リソース API を使用してユーザー・ワークスペースのリソース・ツリーを変更する場合には、 ユーザー・リソース・オブジェクトが更新されるだけでなく、ファイルがファイル・システム内で変更されます。 一方、プラットフォームの API の外部で発生するリソース・ファイルへの変更についてはどうなるでしょう。
リソースへの外部変更は、リソース・プラグインによって検出されるまで、 ワークスペースおよびリソース・オブジェクト内には反映されません。 クライアントはリソース API を使用して、ユーザーが介入することなく、ワークスペースおよびリソース・オブジェクトを、 静的にローカル・ファイル・システムと調和させることができます。 ユーザーは、ワークベンチのリソース・ナビゲーター・ビューで、 常に明示的にリフレッシュを強制できます。
注 : リソース API の中のほとんどのメソッドには、ファイル・システムと同期がとれていないリソースを処理する方法を指定する、 強制パラメーターが含まれています。 それぞれのメソッドごとの API 参照は、このパラメーターに関する特定情報を提供します。API の追加メソッドによって、IResource.refreshLocal(int depth、IProgressMonitor monitor) などのファイル・システム・リフレッシュを、方針に基づいてコントロールできます。正しい使用法およびコストについて詳しくは、IResource を参照してください。