逻辑模型集成的资源库路线图

为了提供对逻辑模型的全面支持,资源库提供程序可以执行下列步骤:

  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)或者日期标记 June 28, 2006 来检出该项目。

对资源映射添加操作

基本资源映射 API

资源映射 API 包含下列类:

在资源映射中,有两类插件特别重要。第一类插件提供由工作空间资源组成的模型或者保存在工作空间资源中的模型,第二类插件对资源执行操作。前一种情况将在模型路线图中阐述,后一种情况将在下一节说明。

资源映射和对象添加项

向可适应扩展点添加扩展的插件将必须进行两项更改,这样才能支持新的 ResourceMapping API:

  1. 在插件的 plugin.xml 文件中,更新 popupMenus 扩展点的所有 objectContributions, 以便面向 ResourceMapping 而不是 IResource(这适用于那些适合于更新的插件)。
  2. 更新插件的操作,使其处理 ResourceMapping 而不是 IResource,并遵循遍历中提供的深度约束。

现在,如果操作可以应用于多个资源,对 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 的对象。此传递性关联由工作台处理。可以使用启用表达式来对添加到资源映射的添加项进行过滤。已添加了根据项目持久属性进行过滤的表达式,从而允许资源库提供程序将它们的菜单显示在映射到它们的资源库的项目中。

将向已添加到 ResourceMapping 类的操作提供包含一个或多个 ResourceMapping 的所选项。这些操作负责将资源映射转换为一组要处理的资源。这可以通过调用 getTraversals 获取映射的遍历来实现。遍历用来使遍历的客户机能够根据所遍历的资源的深度对其操作进行优化。客户机可以手工方式遍历资源,也可以将该资源和深度用作负责执行工作的操作的输入。例如,如果用户对 Java 包执行 CVS 更新,并且该 Java 包资源映射将映射到深度为 1 的文件夹,则 CVS 将发出适当的命令(“cvs update -l”),这将对该包所表示的文件夹执行影子更新。

虽然可以直接从所选资源映射获取一组遍历,但有一些模型关系(或资源库关系)可能要求在操作中包括其他资源或模型元素。下一节描述如何确保在操作中包括所有必需的资源。

操作作用域

对于小组操作来说,需要将所选映射转换为一组要处理的映射。此过程涉及查询所有模型提供程序,以确保它们包括在对与它们的启用规则相匹配的资源执行的操作中。用来描述所要处理的整组资源映射的术语是操作作用域。在这方面,已提供了下列 API:

SynchronizationScopeManager 类的 initialize(IProgressMonitor) 方法用于处理以下整个过程:将一组输入资源映射转换为完整的一组所要处理的映射以及完整的一组涵盖这些映射的遍历。资源库提供程序可以通过下列方法对此过程进行定制:

  1. 提供 RemoteResourceMappingContext,以便在从资源映射中获取资源遍历时使用。
  2. 覆盖 SynchronizationScopeManager,以根据需要对作用域管理过程进行定制。

下两节对这两种方法进行了更详细的描述。

远程资源映射上下文

为了保证将所有必需资源都包括在小组操作中,模型提供程序可能需要能够了解资源库中一个或多个资源的状态。对于某些模型来说,这一点不是必需的。例如,Java 包是访问深度为 1 的容器,而与模型的远程状态无关。在这种情况下,资源库提供程序可以很容易地确定在落实时是否应该包括传出删除或者在更新时是否应该包括传入添加。但是,组成某些逻辑模型的资源可能会随着时间的推移而改变。例如,组成模型元素的资源可能依赖于清单文件的内容(或者另一种类似的机制)。为了使资源映射返回正确的遍历,资源映射必须访问清单文件的远程内容(如果它与本地内容不同),以确定是否需要包括其他资源。这些资源在工作空间中可能不存在,但资源库提供程序会知道如何确保使它们在执行所选操作后存在。

为了支持这些更为复杂的模型,可以将 RemoteResourceMappingContext 传递给 ResourceMapping#getTraversals 方法。如果提供了上下文,映射就可以使用它来确保所有必需资源都包括在遍历中。如果未提供上下文,则映射可以假定只有本地状态才有意义。

远程资源映射上下文提供了三种基本查询:

上面第一个问题的回答依赖于所执行的操作的类型。通常,更新和合并操作是三向的,而比较和替换操作是双向的(至少对于 CVS 来说情况如此)。

Eclipse 小组 API 提供了 Subscriber 类,这个类定义了用于在本地工作空间与远程服务器之间提供同步状态的 API。提供了使用 Subscriber 来访问必需远程状态的 SubscriberResourceMappingContext。具有 Subscriber 的客户机不必执行任何其他工作即可获取资源映射上下文。

创建 SynchronizationScopeManager 的子类

可以创建 SynchronizationScopeManager 类的子类,以便对作用域生成和管理过程进行定制。创建作用域管理器的子类的两个主要原因是:

  1. 资源库提供程序由于某些资源库级关系(例如,更改集)而需要包括其他资源。可以通过覆盖 adjustInputTraversals(ResourceTraversal[]) 方法来实现此目的。
  2. 同步具有较长的生命周期(例如,“同步”视图和对话框),需要能够对作用域更改作出反应。ISynchronizationScopeParticipant 接口定义了一个 API,模型提供程序可以使用该 API 来参与作用域管理过程。SubscriberScopeManager 类是 SynchronizationScopeManager 的基于 Subscriber 的子类,这个子类处理作用域管理过程中的参与者。为何需要执行此类过程呢?工作集就是一个示例。如果工作集是作用域中的其中一个资源映射,那么,在将资源添加到工作集时,作用域所涵盖的遍历集将扩大。

基于模型的合并

要求模型参与操作的主要资源库操作类型是合并。在许多情况下,模型只需要在文件级参与操作。因此,引入了 IStorageMerger API,从而允许模型提供程序添加合并程序来合并具有特定扩展名或内容类型的文件。但是,在某些情况下,模型可能需要其他上下文才能正确地参与合并。为此,我们引入了 IResourceMappingMergerIMergeContext API。

合并操作仍由与资源库提供程序相关联的操作触发。但是,一旦用户请求了合并类型的操作,资源库提供程序就需要使模型提供程序参与合并过程,以确保合并操作不会以任何方式破坏模型。

资源库提供程序 API 有两个主要部分与基于模型的合并支持相关。

  1. 用于描述合并所涉及资源的同步状态的 API。
  2. 用于允许模型提供程序合并模型元素的 API。
下列各节对这两个部分进行了描述。

用于同步状态描述的 API

对于基于模型的合并来说,一个重要方面是用于将所涉及资源的同步状态通知模型提供程序的 API。下列接口用于描述同步状态:

为所有这些接口提供了抽象类,所遵循的约定是类名与除去了“I”前缀的接口名相匹配。资源库提供程序必须覆盖的唯一一个类是 ResourceDiff 类,其目的是提供适当的前文件修订版和后文件修订版。

用于模型合并的 API

IMergeContext 接口使用其他支持合并的方法扩展了同步上下文。提供了用于执行下列操作的回调方法:

提供了抽象的 MergeContext 类,这个类包含大多数合并行为的缺省实现,并且还使用 IStorageMerger 来执行三向合并。此外,还提供了一个 SubscriberMergeContext类,这个类用于处理与合并上下文相关联的同步状态描述的填充与维护。

提供了操作类 ModelMergeOperation,这个类使用 IResourceMappingMerger API 来执行基于模型的合并操作。子类需要覆盖 initializeContext(IProgressMonitor) 方法以返回合并上下文。该操作使用此上下文来尝试执行基于模型的无外设合并。如果发生冲突,则将合并预览工作留给子类处理。正如我们将在下一节看到的那样,有一个 ModelParticipantMergeOperation,它通过使用 ModelSynchronizeParticipant 来提供预览功能。

小组查看器中的模型内容

通过使用 Eclipse 3.2 中引入的公共导航器框架,支持在小组操作中显示逻辑模型。通过使用 org.eclipse.team.ui.teamContentProvider 扩展点,逻辑模型可以使内容扩展与模型提供程序相关联。小组提供程序通过 ITeamContentProviderManager 来访问这些内容提供程序。

在下列几种情况下,小组提供程序可能希望显示逻辑模型:

ModelSynchronizeParticipant 提供了集成到“同步”视图或任何其他能够显示 iSynchronizePages 的容器的能力。参与者同时使用预先存在的同步参与者功能和公共导航器功能,以允许小组提供程序和模型对工具栏、上下文菜单以及合并预览的其他方面进行定制。ModelSynchronizeParticipant 提供了下列各项:

以下步骤核对表用于为特定小组提供程序定制模型同步参与者:

以下 XML 片段举例说明了如何注册 CVS 参与者类以及如何定义它的查看器。

   <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 添加了一些方法。小组提供程序可以选择为项目集功能提供支持,以便允许逻辑模型执行远程浏览和项目装入。

修饰模型元素

小组提供程序可以对模型元素进行修饰,其方法是将模型元素的轻量级修饰符转换为适用于资源映射,并且转换方式与将对象添加项转换为资源映射的方式相同。但是,逻辑模型元素修饰的一个方面存在问题。如果模型元素与资源之间不存在一对一的映射关系,则当底层资源改变时,该模型元素可能无法接收到标签更新。

为了解决此问题,引入了 ITeamStateProvider,以使模型提供程序能够访问可能会影响小组修饰的状态更改。此外,模型视图还可以使用 SynchronizationStateTester 来确定何时需要更新逻辑模型元素的标签。此 API 依靠 ITeamStateProvider 接口来确定资源的小组状态何时已更改,并且可以作为 IDecorationContext 的组成部分传递给小组修饰符。