論理モデル統合のリポジトリー・ロードマップ

論理モデルをフル・サポートするために、リポジトリー・プロバイダーは以下のステップを実行できます。

  1. ResourceMapping に適応する要素に適切なリポジトリー操作を提供します。
  2. ISynchronizationScope とサポートされている API を使用することで、リソース・マッピングで実行された操作に、適切なモデル要素とリソースのすべてが含まれるようにします。
  3. モデル・プロバイダーは、 IMergeContext インターフェースと対応する API により、ヘッドレス・マージに参加できます。
  4. モデル・プロバイダーは、マージに関係するモデルに teamContentProviders を使用することで、マージ・プレビューに参加できます。 ModelSynchronizeParticipant クラスは、モデル・コンテンツ、マージ・コンテキスト、および比較フレームワークの間の関係の管理を助ける目的で提供されています。
  5. IFileHistoryProvider API によりワークスペース・ファイルのヒストリーへのアクセスを提供します。
  6. org.eclipse.core.filesystem プラグインの Eclipse ファイル・システム API を使用してリモート構成へのアクセスを提供し、これを ProjectSetCapability によりワークスペース・プロジェクトにリンクします。
  7. SynchronizationStateTester API で使用するワークスペース Subscriber を提供することで、論理モデル要素の装飾をサポートします。

以下のセクションでは、これらのポイントのそれぞれについて詳細に説明します。 org.eclipse.team.examples.filesystem プラグインには、これらの点のいくつかを示すサンプルが含まれています。 CVS リポジトリーのプロジェクトを確認して、本チュートリアルを読む際の参考にすることができます。 特記事項: 例にあるプラグインのソース・コードは、変更される場合があります。この例で使用されているコードに一致するコピーを入手するには、 3.2 バージョン・タグ (おそらく R3_2)、または 2006 年 6 月 28 日の日付タグを使用してプロジェクトを調べてください。

アクションのリソース・マッピングへのコントリビュート

基本リソース・マッピング API

リソース・マッピング API は、以下のクラスから構成されています。

リソース・マッピングでは、以下の 2 つのタイプのプラグインが重要です。ワークスペースのリソースを構成する、またはそこに保持されるモデルを提供するプラグインと、リソース上で操作を実行するプラグインです。前者はモデル・ロードマップで扱い、後者は次のセクションで扱います。

リソース・マッピングとオブジェクト・コントリビューション

拡張機能を適応性のある拡張ポイントにコントリビュートするプラグインは、新規の ResourceMapping API をサポートするために次の 2 つの変更を行う必要があります。

  1. plugin.xml ファイル内にある popupMenus 拡張ポイントの objectContributions を、IResource の代わりにターゲットの ResourceMapping に更新します (これが適切であるものに対して)。
  2. 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 に、これが用意されています。

SynchronizationScopeManager クラス の initialize(IProgressMonitor) メソッドは、リソース・マッピングの入力セットを、操作対象マッピングの完全セットおよびこれらのマッピングを扱う全探索の完全セットに変換するプロセス全体を処理します。リポジトリー・プロバイダーは、以下を実行することでプロセスを調整できます。

  1. リソース・マッピングからリソース全探索を取得する際に使用する RemoteResourceMappingContext を提供します。
  2. 必要に応じて、スコープ管理プロセスを調整するために、 SynchronizationScopeManager をオーバーライドします。

次の 2 つのセクションで、これらのポイントについて詳しく説明します。

リモート・リソース・マッピング・コンテキスト

すべての必要なリソースがチーム操作に含まれることを保証するために、モデル・プロバイダーは、リポジトリー内の 1 つ以上のリソースの状態を確認できるようにする必要があります。一部のモデルでは、これは必要ありません。例えば、Java パッケージは、モデルのリモート状態に関係なく、深さ 1 となるコンテナーです。これにより、リポジトリー・プロバイダーは、コミット時に発信削除を組み込む必要があるか、または更新時に着信追加を組み込む必要があるかを容易に判別できます。ただし、一部の論理モデルを構成するリソースは、時間の経過と共に変更される場合があります。例えば、モデル要素を構成するリソースは、マニフェスト・ファイル (または、他の類似したメカニズム) のコンテンツに依存する場合があります。リソース・マッピングが適切な全探索を戻すようにするには、組み込む必要がある追加リソースがあるかどうかを確認するために、マニフェスト・ファイルのリモート・コンテンツ (ローカル・コンテンツと異なる場合) にアクセスする必要があります。これらの追加リソースはワークスペースに存在しない場合がありますが、リポジトリー・プロバイダーは、選択したアクションが実行された際に、それらが確実に実行されるようにする方法を認識しています。

これらのより複雑なモデルをサポートするために、RemoteResourceMappingContextResourceMapping#getTraversals メソッドに渡すことができます。コンテキストが提供されると、マッピングはそれを使用して、すべての必要なリソースが全探索に含まれるようにすることができます。コンテキストが提供されない場合、マッピングはローカル状態のみが重要であると想定します。

リモート・リソース・マッピング・コンテキストは、次の 3 つの基本照会を提供します。

上記の最初の質問の答えは、実行される操作のタイプによって決まります。通常の場合、更新およびマージは 3 方向で、比較および置換操作 (少なくとも、CVS の場合) は両方向です。

Eclipse Team API には、ローカル・ワークスペースとリモート・サーバー間の同期状態を提供するための API を定義する Subscriber クラスが含まれています。必要なリモート状態にアクセスするために Subscriber を使用する SubscriberResourceMappingContext が提供されています。 Subscriber を持つクライアントは、追加作業を行ってリソース・マッピング・コンテキストを取得する必要はありません。

SynchronizationScopeManager のサブクラス化

SynchronizationScopeManager クラスは、有効範囲の生成および管理プロセスを調整するためにサブクラス化できます。スコープ・マネージャーをサブクラス化する主な 2 つの理由は、次のとおりです。

  1. リポジトリー・プロバイダーが、あるリポジトリー・レベルの関係のために追加リソースを組み込む必要がある (例えば、変更セット)。これを行うには、 adjustInputTraversals(ResourceTraversal[]) メソッドをオーバーライドします。
  2. 同期のライフ・サイクル (例えば、ビューとダイアログの同期) が長くなり、有効範囲の変更に対応する能力が必要である。 ISynchronizationScopeParticipant インターフェースは、モデル・プロバイダーが有効範囲の管理プロセスに参加するために使用できる API を定義します。 SubscriberScopeManager クラスは、有効範囲の管理プロセスの Participant を含む SynchronizationScopeManagerSubscriber ベースのサブクラスです。このタイプのプロセスが必要な理由の一例としては、ワーキング・セットがあります。ワーキング・セットが有効範囲内のリソース・マッピングの 1 つである場合、リソースがワーキング・セットに追加されると、その有効範囲でカバーされる全探索のセットが増加します。

モデル・ベースのマージ

モデルの参加を必要とする主なリポジトリー操作タイプは、マージです。多くのケースの場合、モデルのみファイル・レベルで参加する必要があります。このため、特定の拡張子またはコンテンツ・タイプのファイルをマージするために使用する必要があるマージャーをモデル・プロバイダーがコントリビュートできるように、IStorageMerger API が導入されました。しかし、一部のケースの場合、モデルはマージに適切に参加するために追加コンテキストを必要とします。この目的のために、IResourceMappingMerger API と IMergeContext API が導入されました。

マージ操作は、現在も、リポジトリー・プロバイダーに関連付けられたアクションによって起動されます。しかし、マージ・タイプ操作がユーザーによって要求されると、リポジトリー・プロバイダーはモデル・プロバイダーをマージ・プロセスに関与させて、何らかの方法でマージによってモデルが破壊されないようにする必要があります。

モデル・ベースのマージ・サポートに関係して、リポジトリー・プロバイダー API に 2 つの主要部分があります。

  1. マージに関与するリソースの同期状態を記述する API
  2. モデル・プロバイダーがモデル要素をマージできるようにする API
以下のセクションでは、これらの 2 つの部分について説明します。

同期状態の記述用 API

モデル・ベース・マージの重要な側面の 1 つとして、モデル・プロバイダーに関わるリソースの同期状態の通信に使用される API があります。以下のインターフェースは、同期状態の記述に使用されます。

抽象クラスは、クラス名が接頭部「I」を取り除いたインターフェース名に一致するという規則を持つ、これらすべてのインターフェースに提供されます。リポジトリー・プロバイダーが上書きする必要のある唯一のクラスは、 ResourceDiff クラスで、適切な (改訂前、改訂後の) ファイル改訂を提供できるようになっています。

モデル・マージ用 API

IMergeContext インターフェースは、マージをサポートする追加メソッドを使用して同期コンテキストを拡張します。以下を行うためのコールバック・メソッドがあります。

MergeContext 抽象クラスが提供されています。このクラスは、マージ動作の大部分に対するデフォルト実装を含み、さらに IStorageMerger を使用して 3 方向マージも実行します。 SubscriberMergeContext クラスも提供されています。このクラスは、マージ・コンテキストに関連付けられている同期状態記述の取り込みと保守を処理します。

Operation クラス ModelMergeOperation が提供されています。このクラスは、IResourceMappingMerger API を使用して、モデル・ベースのマージ操作を実行します。サブクラスは、マージ・コンテキストを戻すために、 initializeContext(IProgressMonitor) メソッドを上書きする必要があります。この操作では、このコンテキストを使用してヘッドレス・モデル・ベース・マージを試みます。競合が存在する場合は、マージのプレビューがサブクラスに残されます。次のセクションで説明しますが、 ModelSynchronizeParticipant を使用してプレビュー機能を提供する ModelParticipantMergeOperation があります。

チーム・ビューアーのモデル・コンテンツ

チーム操作内での論理モデルの表示に対するサポートは、 Eclipse 3.2 で導入された共通ナビゲーター・フレームワークを使用して提供されます。論理モデルは、org.eclipse.team.ui.teamContentProvider 拡張ポイントを使用して、コンテキスト拡張機能をモデル・プロバイダーに関連付けることができます。チーム・プロバイダーは、 ITeamContentProviderManager を介してこれらのコンテンツ・プロバイダーにアクセスします。

チーム・プロバイダーが論理モデルを表示する必要のある場所がいくつかあります。

ModelSynchronizeParticipant は、同期化ビュー、または iSynchronizePages を表示できる任意のコンテナーへの統合を提供します。 Participant は、既存する同期 Participant 機能と共通ナビゲーター機能の両方を使用して、チーム・プロバイダーとモデルがマージ・プレビューのツールバー、コンテキスト・メニュー、およびその他の外観を調整できるようにします。 The ModelSynchronizeParticipant は以下を提供します。

以下は、特定のチーム・プロバイダーのモデル同期 Participant を調整するステップのチェックリストです。

以下の 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 に加えて、汎用のファイル・ヒストリー・ビューが追加されています。これにより、チーム・プロバイダーはファイル/リソース・ヒストリーを共用ビューに表示できます。また、モデルは、ファイルに直接マップされない要素のモデル要素ヒストリーを表示できます。ヒストリー・ビューは、ページ・ベースのビューで、以下の方法で選択済み要素のページを取得します。

プロジェクト設定機能

プロジェクトとリモート・コンテンツ間のマッピングの識別に使用される参照ストリングと、org.eclipse.core.filesystem.filesystems 拡張ポイントで登録されたファイル・システム・スキームを識別する URI の間での変換をサポートするために、メソッドが ProjectSetCapability に追加されています。チーム・プロバイダーは、論理モデルがリモート・ブラウズとプロジェクト・ロードを実行できるようにこのサポートをオプションとして提供します。

モデル要素の装飾

チーム・プロバイダーは、単純なデコレーターをリソース・マッピングの作業に変換することでモデル要素を装飾できます。これは、オブジェクト・コントリビューションがリソース・マッピングの作業に変換されるのと同様です。ただし、論理モデル要素の装飾には、問題となる側面が 1 つあります。モデル要素にリソースとの 1 対 1 のマッピングがない場合、モデル要素は、基本となるリソースが変更された場合にラベルの更新を受信しないことがあります。

この問題に対処するため、チーム装飾に影響を与え得る状態変更にモデル・プロバイダーがアクセスできるように ITeamStateProvider が導入されました。また、モデル・ビューは SynchronizationStateTester を使用して、論理モデル要素のラベルの更新が必要になる時期を判別できます。この API は、リソースのチーム状態が変更された時期、および IDecorationContext の一部としてチーム・デコレーターに渡すことができる時期を判別する際、ITeamStateProvider インターフェースに依存します。