論理モデルをフル・サポートするために、リポジトリー・プロバイダーは以下のステップを実行できます。
ResourceMapping
に適応する要素に適切なリポジトリー操作を提供します。ISynchronizationScope
とサポートされている
API を使用することで、リソース・マッピングで実行された操作に、適切なモデル要素とリソースのすべてが含まれるようにします。
IMergeContext
インターフェースと対応する API により、ヘッドレス・マージに参加できます。
teamContentProviders
を使用することで、マージ・プレビューに参加できます。
ModelSynchronizeParticipant
クラスは、モデル・コンテンツ、マージ・コンテキスト、および比較フレームワークの間の関係の管理を助ける目的で提供されています。
IFileHistoryProvider
API によりワークスペース・ファイルのヒストリーへのアクセスを提供します。
ProjectSetCapability
によりワークスペース・プロジェクトにリンクします。
SynchronizationStateTester
API で使用するワークスペース Subscriber
を提供することで、論理モデル要素の装飾をサポートします。
以下のセクションでは、これらのポイントのそれぞれについて詳細に説明します。 org.eclipse.team.examples.filesystem プラグインには、これらの点のいくつかを示すサンプルが含まれています。 CVS リポジトリーのプロジェクトを確認して、本チュートリアルを読む際の参考にすることができます。 特記事項: 例にあるプラグインのソース・コードは、変更される場合があります。この例で使用されているコードに一致するコピーを入手するには、 3.2 バージョン・タグ (おそらく R3_2)、または 2006 年 6 月 28 日の日付タグを使用してプロジェクトを調べてください。
リソース・マッピング API は、以下のクラスから構成されています。
Object getModelObject()
: マッピングの派生元 (または適応元) のモデル・オブジェクトです。
ResourceTraversal[]
getTraversals(ResourceMappingContext, IProgressMonitor)
: モデル・オブジェクトを構成するリソースをカバーしたリソース全探索です。
ResourceTraversal
には、一連のリソースと深さフラグが含まれています。このフラグは、全探索内のリソースが発信モデル・オブジェクトに関連付けられている深さを示すものです。リソース全探索は、クライアント (リポジトリー・プロバイダーなど) がその操作を可能な限り効率的に実行できる方法でモデルのコンテンツを記述するために、リソース・マッピングによってクライアントに提供されています。重要なメソッドは、以下のものです。
getResources()
getDepth()
ResourceMappingContext
と RemoteResourceMappingContext
の使用は、いくぶん複雑であり、後で説明します。リソース・マッピングでは、以下の 2 つのタイプのプラグインが重要です。ワークスペースのリソースを構成する、またはそこに保持されるモデルを提供するプラグインと、リソース上で操作を実行するプラグインです。前者はモデル・ロードマップで扱い、後者は次のセクションで扱います。
拡張機能を適応性のある拡張ポイントにコントリビュートするプラグインは、新規の ResourceMapping
API をサポートするために次の 2 つの変更を行う必要があります。
IResource
の代わりにターゲットの ResourceMapping
に更新します (これが適切であるものに対して)。
IResource
の代わりに、
ResourceMapping
で処理するアクションを更新し、全探索で指定されている深さの制約を順守します。
オブジェクト・コントリビューションを IResource
に追加するプラグインは、アクションを複数のリソースに適用できる場合は、代わりに ResourceMapping
に追加できます。以下は、リソース・マッピングに適応するオブジェクトにメニュー・アクションをコントリビュートする XML スニペットです。
<extension point="org.eclipse.ui.popupMenus"> <objectContribution objectClass="org.eclipse.core.resources.mapping.ResourceMapping" adaptable="true" id="org.eclipse.team.ccvs.ui.ResourceMapperContributions"> <enablement>
<adapt type="org.eclipse.core.resources.mapping.ResourceMapping">
<test
property="org.eclipse.core.resources.projectPersistentProperty"
args="org.eclipse.team.core.repository,org.eclipse.team.cvs.core.cvsnature" />
</adapt>
</enablement>
<action
label="%UpdateAction.label"
definitionId="org.eclipse.team.cvs.ui.update"
class="org.eclipse.team.internal.ccvs.ui.actions.UpdateAction"
tooltip="%UpdateAction.tooltip"
menubarPath="team.main/group2"
id="org.eclipse.team.cvs.ui.update">
</action>
...
</objectContribution>
</extension>
ResourceMapping
へのコントリビューションは、IResource
に適応するオブジェクトに自動的に適用されます。この過渡的関連は、ワークベンチによって処理されます。リソース・マッピングへのコントリビューションのフィルタリングは、Enablement 式 を使用して行うことができます。リポジトリー・プロバイダーがリポジトリーにマップされているプロジェクトにメニューを表示できるように、プロジェクトの永続的プロパティーによるフィルタリングの式が追加されています。
ResourceMapping
クラスにコントリビュートされているアクションは、1 つ以上の ResourceMapping
を含む選択項目を与えられます。リソース・マッピングを、操作対象のリソース・セットに変換することは、アクションの役割です。これを行うには、getTraversals
を呼び出して、マッピングの全探索を取得します。全探索は、全探索のクライアントが全探索するリソースの深さに基づいて操作を最適化できるようにするために使用されます。クライアントは、リソースを手動で全探索できます。あるいは、リソースと深さを、アクションがその作業を委譲する操作への入力として使用できます。例えば、ユーザーが Java パッケージで CVS 更新を実行し、その Java パッケージのリソース・マッピングが深さ 1 のフォルダーにマップされている場合、CVS は適切なコマンド (不明のものには「cvs update -l」) を発行します。このコマンドは、パッケージが表すフォルダーでシャロー更新を実行することになります。
選択済みリソース・マッピングから全探索のセットを直接取得することは可能ですが、操作に追加リソースまたはモデル要素の包含を必要とするモデル関係 (またはリポジトリー関係) があります。次のセクションでは、すべての必須リソースを操作に確実に含める方法について説明します。
チーム操作の場合、選択済みマッピングは、操作対象のマッピング・セットに変換する必要があります。このプロセスでは、使用可能化の規則に一致するリソースに対する操作にモデル・プロバイダーが含まれるようにするために、すべてのモデル・プロバイダーを調べる必要があります。操作対象のリソース・マッピングの完全セットを記述するために使用する用語は、操作の有効範囲 です。以下の API に、これが用意されています。
ISynchronizationScope
:
操作の有効範囲にアクセスするための API を定義するインターフェース。操作対象のリソース・マッピング、および有効範囲のビルド・プロセス時に計算されたリソース・マッピングの全探索のすべてに対するアクセスを可能にします。
ISynchronizationScopeManager
:
有効範囲の作成および管理用の API を定義するインターフェース。
SynchronizationScopeManager
:
ISynchronizationScopeManager
API のデフォルト実装を提供する拡張可能クラス。
ModelOperation
:
提供されたスコープ・マネージャーを使用して有効範囲を生成し、モデル・プロバイダー関係により、追加のリソースまたはマッピングがその操作に含まれている場合はプロンプトを表示する拡張可能 Operation クラス。
SynchronizationScopeManager
クラス の initialize(IProgressMonitor) メソッドは、リソース・マッピングの入力セットを、操作対象マッピングの完全セットおよびこれらのマッピングを扱う全探索の完全セットに変換するプロセス全体を処理します。リポジトリー・プロバイダーは、以下を実行することでプロセスを調整できます。
RemoteResourceMappingContext
を提供します。
SynchronizationScopeManager
をオーバーライドします。
次の 2 つのセクションで、これらのポイントについて詳しく説明します。
すべての必要なリソースがチーム操作に含まれることを保証するために、モデル・プロバイダーは、リポジトリー内の 1 つ以上のリソースの状態を確認できるようにする必要があります。一部のモデルでは、これは必要ありません。例えば、Java パッケージは、モデルのリモート状態に関係なく、深さ 1 となるコンテナーです。これにより、リポジトリー・プロバイダーは、コミット時に発信削除を組み込む必要があるか、または更新時に着信追加を組み込む必要があるかを容易に判別できます。ただし、一部の論理モデルを構成するリソースは、時間の経過と共に変更される場合があります。例えば、モデル要素を構成するリソースは、マニフェスト・ファイル (または、他の類似したメカニズム) のコンテンツに依存する場合があります。リソース・マッピングが適切な全探索を戻すようにするには、組み込む必要がある追加リソースがあるかどうかを確認するために、マニフェスト・ファイルのリモート・コンテンツ (ローカル・コンテンツと異なる場合) にアクセスする必要があります。これらの追加リソースはワークスペースに存在しない場合がありますが、リポジトリー・プロバイダーは、選択したアクションが実行された際に、それらが確実に実行されるようにする方法を認識しています。
これらのより複雑なモデルをサポートするために、RemoteResourceMappingContext
を ResourceMapping#getTraversals
メソッドに渡すことができます。コンテキストが提供されると、マッピングはそれを使用して、すべての必要なリソースが全探索に含まれるようにすることができます。コンテキストが提供されない場合、マッピングはローカル状態のみが重要であると想定します。
リモート・リソース・マッピング・コンテキストは、次の 3 つの基本照会を提供します。
上記の最初の質問の答えは、実行される操作のタイプによって決まります。通常の場合、更新およびマージは 3 方向で、比較および置換操作 (少なくとも、CVS の場合) は両方向です。
Eclipse Team API には、ローカル・ワークスペースとリモート・サーバー間の同期状態を提供するための API を定義する Subscriber
クラスが含まれています。必要なリモート状態にアクセスするために Subscriber
を使用する SubscriberResourceMappingContext
が提供されています。
Subscriber
を持つクライアントは、追加作業を行ってリソース・マッピング・コンテキストを取得する必要はありません。
SynchronizationScopeManager
クラスは、有効範囲の生成および管理プロセスを調整するためにサブクラス化できます。スコープ・マネージャーをサブクラス化する主な 2 つの理由は、次のとおりです。
ISynchronizationScopeParticipant
インターフェースは、モデル・プロバイダーが有効範囲の管理プロセスに参加するために使用できる API を定義します。
SubscriberScopeManager
クラスは、有効範囲の管理プロセスの Participant を含む SynchronizationScopeManager
の Subscriber
ベースのサブクラスです。このタイプのプロセスが必要な理由の一例としては、ワーキング・セットがあります。ワーキング・セットが有効範囲内のリソース・マッピングの 1 つである場合、リソースがワーキング・セットに追加されると、その有効範囲でカバーされる全探索のセットが増加します。
モデルの参加を必要とする主なリポジトリー操作タイプは、マージです。多くのケースの場合、モデルのみファイル・レベルで参加する必要があります。このため、特定の拡張子またはコンテンツ・タイプのファイルをマージするために使用する必要があるマージャーをモデル・プロバイダーがコントリビュートできるように、IStorageMerger
API が導入されました。しかし、一部のケースの場合、モデルはマージに適切に参加するために追加コンテキストを必要とします。この目的のために、IResourceMappingMerger
API と
IMergeContext
API が導入されました。
マージ操作は、現在も、リポジトリー・プロバイダーに関連付けられたアクションによって起動されます。しかし、マージ・タイプ操作がユーザーによって要求されると、リポジトリー・プロバイダーはモデル・プロバイダーをマージ・プロセスに関与させて、何らかの方法でマージによってモデルが破壊されないようにする必要があります。
モデル・ベースのマージ・サポートに関係して、リポジトリー・プロバイダー API に 2 つの主要部分があります。
モデル・ベース・マージの重要な側面の 1 つとして、モデル・プロバイダーに関わるリソースの同期状態の通信に使用される API があります。以下のインターフェースは、同期状態の記述に使用されます。
抽象クラスは、クラス名が接頭部「I」を取り除いたインターフェース名に一致するという規則を持つ、これらすべてのインターフェースに提供されます。リポジトリー・プロバイダーが上書きする必要のある唯一のクラスは、
ResourceDiff
クラスで、適切な (改訂前、改訂後の) ファイル改訂を提供できるようになっています。
IMergeContext インターフェースは、マージをサポートする追加メソッドを使用して同期コンテキストを拡張します。以下を行うためのコールバック・メソッドがあります。
MergeContext 抽象クラスが提供されています。このクラスは、マージ動作の大部分に対するデフォルト実装を含み、さらに IStorageMerger を使用して 3 方向マージも実行します。 SubscriberMergeContext クラスも提供されています。このクラスは、マージ・コンテキストに関連付けられている同期状態記述の取り込みと保守を処理します。
Operation クラス ModelMergeOperation
が提供されています。このクラスは、IResourceMappingMerger
API を使用して、モデル・ベースのマージ操作を実行します。サブクラスは、マージ・コンテキストを戻すために、
initializeContext(IProgressMonitor)
メソッドを上書きする必要があります。この操作では、このコンテキストを使用してヘッドレス・モデル・ベース・マージを試みます。競合が存在する場合は、マージのプレビューがサブクラスに残されます。次のセクションで説明しますが、
ModelSynchronizeParticipant を使用してプレビュー機能を提供する ModelParticipantMergeOperation
があります。
チーム操作内での論理モデルの表示に対するサポートは、
Eclipse 3.2 で導入された共通ナビゲーター・フレームワークを使用して提供されます。論理モデルは、org.eclipse.team.ui.teamContentProvider
拡張ポイントを使用して、コンテキスト拡張機能をモデル・プロバイダーに関連付けることができます。チーム・プロバイダーは、
ITeamContentProviderManager
を介してこれらのコンテンツ・プロバイダーにアクセスします。
チーム・プロバイダーが論理モデルを表示する必要のある場所がいくつかあります。
ModelOperation
クラスは、ユーザーに有効範囲の拡張を通知するための、登録済みチーム・コンテンツ・プロバイダーを使用するプロンプトを提供します。
ModelSynchronizeParticipant
は、同期化ビュー、または iSynchronizePages
を表示できる任意のコンテナーへの統合を提供します。
Participant は、既存する同期 Participant 機能と共通ナビゲーター機能の両方を使用して、チーム・プロバイダーとモデルがマージ・プレビューのツールバー、コンテキスト・メニュー、およびその他の外観を調整できるようにします。
The ModelSynchronizeParticipant
は以下を提供します。
以下は、特定のチーム・プロバイダーのモデル同期 Participant を調整するステップのチェックリストです。
ModelSynchronizeParticipant
のサブクラスを作成するチーム・プロバイダーを必要とします。
ISynchronizePageConfiguration.P_VIEWER_ID
を
1 つ前のステップで指定されたビューアーの ID に設定するために、Participant の initializeConfiguration メソッドを上書きします。
MergeActionGroup
のカスタム・サブクラスを提供する createMergeActionGroup を上書きします。
ModelParticipantMergeOperation
のサブクラスを実装します。
以下の XML スニペットは、CVS Participant クラスの登録方法とそのビューアーの定義方法を示しています。
<extension point="org.eclipse.team.ui.synchronizeParticipants"> <participant name="CVS" icon="$nl$/icons/full/eview16/cvs_persp.gif" class="org.eclipse.team.internal.ccvs.ui.mappings.WorkspaceModelParticipant" id="org.eclipse.team.cvs.ui.workspace-participant"> </participant> </extension> <extension point="org.eclipse.ui.navigator.viewer"> <viewer viewerId="org.eclipse.team.cvs.ui.workspaceSynchronization"> <popupMenu allowsPlatformContributions="false" id="org.eclipse.team.cvs.ui.workspaceSynchronizationMenu"> <insertionPoint name="file"/> <insertionPoint name="edit" separator="true"/> <insertionPoint name="synchronize"/> <insertionPoint name="navigate" separator="true"/> <insertionPoint name="update" separator="true"/> <insertionPoint name="commit" separator="false"/> <insertionPoint name="overrideActions" separator="true"/> <insertionPoint name="otherActions1" separator="true"/> <insertionPoint name="otherActions2" separator="true"/> <insertionPoint name="sort" separator="true"/> <insertionPoint name="additions" separator="true"/> <insertionPoint name="properties" separator="true"/> </popupMenu> </viewer> </extension>
モデルがファイルのヒストリーにアクセスできるように、ファイル・ヒストリー API が追加されています。ファイル・ヒストリー API は、以下のインターフェースから構成されています。
この API に加えて、汎用のファイル・ヒストリー・ビューが追加されています。これにより、チーム・プロバイダーはファイル/リソース・ヒストリーを共用ビューに表示できます。また、モデルは、ファイルに直接マップされない要素のモデル要素ヒストリーを表示できます。ヒストリー・ビューは、ページ・ベースのビューで、以下の方法で選択済み要素のページを取得します。
RepositoryProvider
を IHistoryPageSource へ適合させることで取得されます。
IHistoryPageSource
に適合させることで取得されます。
プロジェクトとリモート・コンテンツ間のマッピングの識別に使用される参照ストリングと、org.eclipse.core.filesystem.filesystems
拡張ポイントで登録されたファイル・システム・スキームを識別する URI の間での変換をサポートするために、メソッドが ProjectSetCapability
に追加されています。チーム・プロバイダーは、論理モデルがリモート・ブラウズとプロジェクト・ロードを実行できるようにこのサポートをオプションとして提供します。
チーム・プロバイダーは、単純なデコレーターをリソース・マッピングの作業に変換することでモデル要素を装飾できます。これは、オブジェクト・コントリビューションがリソース・マッピングの作業に変換されるのと同様です。ただし、論理モデル要素の装飾には、問題となる側面が 1 つあります。モデル要素にリソースとの 1 対 1 のマッピングがない場合、モデル要素は、基本となるリソースが変更された場合にラベルの更新を受信しないことがあります。
この問題に対処するため、チーム装飾に影響を与え得る状態変更にモデル・プロバイダーがアクセスできるように ITeamStateProvider
が導入されました。また、モデル・ビューは SynchronizationStateTester
を使用して、論理モデル要素のラベルの更新が必要になる時期を判別できます。この API は、リソースのチーム状態が変更された時期、および IDecorationContext
の一部としてチーム・デコレーターに渡すことができる時期を判別する際、ITeamStateProvider
インターフェースに依存します。