RepositoryProvider を作成した後、理解すべき他のリソース管理メカニズムがあります。
いくつかのケースでは、特定のファイルをリポジトリーの制御下に保持する必要はありません。 例えば、既存のリソースから派生したリソースは、多くの場合リポジトリーから省略することができます。 例えば、コンパイルしたソース・ファイル (Java の「.class」ファイルなど) は、対応するソース (「.java」) ファイルがリポジトリーにあるため省略できます。 リポジトリー・プロバイダーによって生成されたメタデータ・ファイルをバージョン管理することは不適切な場合もあります。 org.eclipse.team.core.ignore 拡張ポイントを使用すると、 プロバイダーは、リポジトリー・プロバイダーの操作で無視すべきファイル・タイプを宣言できます。 例えば、CVS クライアントは、次のように宣言します。
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
マークアップは、無視する必要のあるファイル名パターン、および設定ダイアログでファイル・タイプのデフォルトの選択値を宣言する、 選択済み属性を単に宣言します。 無視するファイルの決定は、最終的にはユーザーの責任で行います。 無視されたファイルのデフォルト・リストから、ファイル・タイプを選択、選択解除、追加、または削除することができます。
いくつかのリポジトリーは、テキスト・ファイルとバイナリー・ファイルとで異なる処理を実装しています。 org.eclipse.team.core.fileTypes 拡張を使用すると、 プラグインは、ファイル・タイプをテキストまたはバイナリー・ファイルとして宣言できます。 例えば、Java ツールは、次を宣言します。
<extension point="org.eclipse.team.core.fileTypes">
<fileTypes extension="java" type="text"/>
<fileTypes extension="classpath" type="text"/>
<fileTypes extension="properties" type="text"/>
<fileTypes extension="class" type="binary"/>
<fileTypes extension="jar" type="binary"/>
<fileTypes extension="zip" type="binary"/>
</extension>
マークアップを使用すると、プラグインは拡張子によってファイル・タイプを定義し、 テキストまたはバイナリーのタイプを割り当てることができます。 無視されたファイルについては、テキストおよびバイナリー・ファイル・タイプのリストの管理は、最終的にユーザーの責任で行います。
プロジェクトには、ローカル・ファイル・システムのプロジェクトのディレクトリー内にないリソースが 含まれている場合もあります。 このようなリソースをリンクされたリソースといいます。
リンクされたリソースは、ファイル・システムを直接操作するリポジトリー・プロバイダーに特定の難題を 投げかけます。 これは、リンクされたリソースがファイル・システム内の直接のプロジェクト・ディレクトリー・ツリーに 故意に存在しないようになっているためです。
以下の特性を示すプロバイダーは、リンクされたリソースによって影響を受ける場合があります。
最初の例では、リンクされたリソースをユーザーが選択し、それに対してプロバイダー操作を試みることを想定します。 プロバイダーはコマンド行クライアントを呼び出すため、最初に IResource.getLocation().toOSString() を 呼び出し、結果のファイル・システム・ロケーションを引数としてコマンド行プログラムに渡すと想定できます。 該当するリソースが、リンクされたリソースである場合、プロジェクト・ディレクトリー・ツリーの 外にファイル/フォルダーが作成されます。 一部のコマンド行クライアントは、この例を想定していないため、この例を処理できない場合があります。 つまり、プロバイダーはリソースのファイル・システム・ロケーションを取得すると、リンクされたリソースを処理する ための追加作業を要求する可能性があります。
2 つ目の例は、プロジェクト・リソースの構造がファイル・システムのファイル/フォルダーの構造と 1 対 1 であると 暗黙的に想定されるという点ではとても似ています。 一般に、プロバイダーが IResource and java.io.File 操作と混同すると、問題が発生する可能性があります。 例えば、リンクの場合、IFile の 親は java.io.File の親とは同じではないので、これらを同じと想定するコードは失敗します。
リンクされたリソースを導入することで、故意ではなくても既存のプロバイダーの妨げになるようなことがないようすることが 重要でした。 特に、ローカル・ファイル・システム構造がプロジェクト構造をミラーリングすると 合理的に想定するプロバイダーについては重要でした。 結果としてデフォルトでは、リンクされたリソースは、そのようなプロバイダーにマップされるプロジェクトに追加できません。 またデフォルトでは、リンクされたリソースを含むプロジェクトはそのプロバイダーと共用できません。
「リンク・フレンドリー」になるために、プロバイダーはリンクされたリソースを持つプロジェクトの バージョン管理を許可すべきですが、リンクされたリソース自体のバージョン管理は否認できます。
かなり複雑な解決方法として、実際にリンクされたリソースのバージョン管理を許可するという方法があります。 ただし、この方法は複雑なシナリオを使用するため、お勧めできません (例えば、ファイルは別のプロバイダーによって 別のプロジェクト・ツリーの下で既にバージョン管理されている場合があります)。 したがって、お勧めの方法は、バージョン管理されていないリンクされたリソースを含む、バージョン管理された プロジェクトをサポートすることです。
true を戻すように RepositoryProvider.canHandleLinkedResources() メソッドをオーバーライドすることによって、リンクされたリソースをサポートするようにリポジトリー・プロバイダーの実装をアップグレードできます。 これを行った後に、リンクされたリソースは、該当するリポジトリー・プロバイダーと共用されるプロジェクトに 置くことができます。 ただし、リポジトリー・プロバイダーは、リンクされたリソースが適切に処理されたことを確認するための ステップを行う必要があります。 上述のように、リポジトリー・プロバイダーがすべてのリンクされたリソースを無視することを強くお勧めします。 つまり、リンクされたリソース (およびその子) は、リポジトリー・プロバイダーによって サポートされるアクションから除外されなければなりません。 さらに、リポジトリー・プロバイダー実装がデフォルトの IMoveDeleteHook を オーバーライドする場合、リポジトリー・プロバイダーは、リンクされたリソースに対するデフォルトの移動および削除の動作を使用する必要があります。
チーム・プロバイダーは IResource.isLinked() を 使用して、リソースがリンクであるかどうかを判別できます。 ただし、このメソッドはリンクのルートに対してのみ true を戻します。 次のコード・セグメントは、リソースがリンクの子であるかどうかを判別するために使用できます。
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
リポジトリー・プロバイダーは、上記のコードが true に評価されるリソースを無視する必要があります。
リポジトリー実装に特定の情報を保管するため、エクストラ・ファイルおよびフォルダーを使用することは、 リポジトリー実装では一般的です。 これらのファイルはワークスペースで必要になる場合がありますが、他のプラグインまたはエンド・ユーザーに対する影響はありません。
チーム・プロバイダーは、 IResource.setTeamPrivateMember(boolean) を使用して、 リソースがチーム・プロバイダーの実装専用であることを指示できます。 新しく作成されたリソースは、デフォルトでは専用メンバーではないため、このメソッドを使用して、 チーム専用としてリソースに明示的にマークを付ける必要があります。 一般的な使用法は、チームのためにプロジェクトが構成され、サブフォルダーが作成されるときに、 プロジェクトのサブフォルダーにチーム専用としてマークを付けることです。
リソース (リソース・デルタ・ツリーなど) を列挙する他のリソース API は、 チーム専用メンバーを組み込むように明示的に要求しないかぎり、それらを除外します。 これは、ほとんどのクライアントがチーム専用リソースを「認識」しないため、ユーザーに対して表示されないことを意味します。 リソース・ナビゲーターは、デフォルトではチーム専用メンバーを表示しませんが、ユーザーは「設定」を介して、 チーム専用リソースを表示するように指示できます。
プロジェクトまたはワークスペース・ルートをチーム専用としてマークを付けようとしても、無視されます。
バージョン管理下にあるプロジェクト内のリソースはリポジトリーで保持されるため、ワークスペース内にプロジェクトを再構成するために必要な、 リポジトリー固有の情報への参照を共有することによって、プロジェクトをチーム・メンバーと共有する可能性があります。 これは、チーム・プロジェクト・セットの特殊なタイプのファイル・エクスポートを使用して行われます。
3.0 では、ProjectSetCapability に API が追加されており、リポジトリー・プロバイダーは、制御下のプロジェクトに対して、プロジェクト削減を実装するクラスを宣言できます。 ユーザーがプロジェクト・セットをエクスポートすることを選択すると、プロジェクト・セットを定義するリポジトリーで構成されたプロジェクトのみ、 エクスポートの候補として表示されます。 この API は、以前のプロジェクト・セット直列化 API (以下を参照) に置き換わるものです。
リポジトリー・プロバイダーのプロジェクト・セット機能クラスは、リポジトリー・プロバイダーと同じ拡張に登録された RepositoryProviderType クラスから取得されます。 以下に例を示します。
<extension point="org.eclipse.team.core.repository">
<repository
typeClass="org.eclipse.team.internal.ccvs.core.CVSTeamProviderType"
class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"
id="org.eclipse.team.cvs.core.cvsnature">
</repository>
</extension>
3.0 以前は、org.eclipse.team.core.projectSets 拡張ポイントを使用することで、リポジトリー・プロバイダーが、制御下のプロジェクトに対してプロジェクト削減を実行するクラスを宣言できました。 ユーザーがプロジェクト・セットをエクスポートすることを選択すると、プロジェクト・セットを定義するリポジトリーで構成されたプロジェクトのみ、 エクスポートの候補として表示されます。
例えば、CVS クライアントは、次のように宣言します。
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
指定されたクラスは IProjectSetSerializer を実装する必要があります。 このインターフェースの使用は 3.0 でもサポートされていますが、推奨されていません。