为了提供对逻辑模型的全面支持,资源库提供程序可以执行下列步骤:
ResourceMapping
的元素添加适当的资源库操作。ISynchronizationScope
和支持 API,确保对资源映射执行的操作包括所有适当的模型元素和资源。IMergeContext
接口和支持 API,允许模型提供程序参与无外设合并。teamContentProviders
,
允许模型提供程序参与合并预览。提供了 ModelSynchronizeParticipant
类来帮助管理模型内容、合并上下文与比较框架之间的关系。IFileHistoryProvider
API,提供对工作空间文件历史记录的访问。ProjectSetCapability
将此访问链接到工作空间项目。SynchronizationStateTester
API 配合使用的工作空间 Subscriber
,支持逻辑模型元素修饰。下列各节更详细地描述了这些任务。org.eclipse.team.examples.filesystem 插件提供的示例演示了如何完成这些任务中的几个任务。在阅读本教程时,您可以从 CVS 资源库中检出该项目并将其用作参考。免责声明:示例插件中的源代码可能会随着时间的推移而更改。要获取与本示例中使用的源代码相匹配的副本,可以使用 3.2 版本标记(很可能是 R3_2)或者日期标记 June 28, 2006 来检出该项目。
资源映射 API 包含下列类:
Object getModelObject()
:用于派生(或改编)映射的模型对象。ResourceTraversal[] getTraversals(ResourceMappingContext, IProgressMonitor)
:资源遍历,此遍历涵盖模型对象中的所有资源。ResourceTraversal
包含一组资源以及深度标志,该标志指示了该遍历中与起始模型对象相关联的资源的深度。资源映射将资源遍历提供给客户机,以便以适当的方式来描述模型内容,从而使客户机(例如资源库提供程序)能够以尽可能高效的方法来执行操作。相关的方法包括:getResources()
getDepth()
ResourceMappingContext
和 RemoteResourceMappingContext
的用法略为复杂,稍后再描述。在资源映射中,有两类插件特别重要。第一类插件提供由工作空间资源组成的模型或者保存在工作空间资源中的模型,第二类插件对资源执行操作。前一种情况将在模型路线图中阐述,后一种情况将在下一节说明。
向可适应扩展点添加扩展的插件将必须进行两项更改,这样才能支持新的 ResourceMapping
API:
ResourceMapping
而不是 IResource
(这适用于那些适合于更新的插件)。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:
ISynchronizationScope
:此接口定义用于访问操作作用域的 API。它提供对所处理的所有资源映射以及作用域构建过程中计算那些映射时与它们相关的遍历的访问。ISynchronizationScopeManager
:此接口定义用于创建和管理作用域的 API。SynchronizationScopeManager
:这个可扩展类提供 ISynchronizationScopeManager
API 的缺省实现。ModelOperation
:这个可扩展操作类使用提供的作用域管理器来生成作用域,并指示是否已由于模型提供程序关系而在操作中包括了其他资源或映射。SynchronizationScopeManager
类的 initialize(IProgressMonitor)
方法用于处理以下整个过程:将一组输入资源映射转换为完整的一组所要处理的映射以及完整的一组涵盖这些映射的遍历。资源库提供程序可以通过下列方法对此过程进行定制:
RemoteResourceMappingContext
,以便在从资源映射中获取资源遍历时使用。SynchronizationScopeManager
,以根据需要对作用域管理过程进行定制。下两节对这两种方法进行了更详细的描述。
为了保证将所有必需资源都包括在小组操作中,模型提供程序可能需要能够了解资源库中一个或多个资源的状态。对于某些模型来说,这一点不是必需的。例如,Java 包是访问深度为 1 的容器,而与模型的远程状态无关。在这种情况下,资源库提供程序可以很容易地确定在落实时是否应该包括传出删除或者在更新时是否应该包括传入添加。但是,组成某些逻辑模型的资源可能会随着时间的推移而改变。例如,组成模型元素的资源可能依赖于清单文件的内容(或者另一种类似的机制)。为了使资源映射返回正确的遍历,资源映射必须访问清单文件的远程内容(如果它与本地内容不同),以确定是否需要包括其他资源。这些资源在工作空间中可能不存在,但资源库提供程序会知道如何确保使它们在执行所选操作后存在。
为了支持这些更为复杂的模型,可以将 RemoteResourceMappingContext
传递给
ResourceMapping#getTraversals
方法。如果提供了上下文,映射就可以使用它来确保所有必需资源都包括在遍历中。如果未提供上下文,则映射可以假定只有本地状态才有意义。
远程资源映射上下文提供了三种基本查询:
上面第一个问题的回答依赖于所执行的操作的类型。通常,更新和合并操作是三向的,而比较和替换操作是双向的(至少对于 CVS 来说情况如此)。
Eclipse 小组 API 提供了 Subscriber
类,这个类定义了用于在本地工作空间与远程服务器之间提供同步状态的 API。提供了使用 Subscriber
来访问必需远程状态的 SubscriberResourceMappingContext
。具有 Subscriber
的客户机不必执行任何其他工作即可获取资源映射上下文。
可以创建 SynchronizationScopeManager
类的子类,以便对作用域生成和管理过程进行定制。创建作用域管理器的子类的两个主要原因是:
ISynchronizationScopeParticipant
接口定义了一个 API,模型提供程序可以使用该 API 来参与作用域管理过程。SubscriberScopeManager
类是 SynchronizationScopeManager
的基于 Subscriber
的子类,这个子类处理作用域管理过程中的参与者。为何需要执行此类过程呢?工作集就是一个示例。如果工作集是作用域中的其中一个资源映射,那么,在将资源添加到工作集时,作用域所涵盖的遍历集将扩大。要求模型参与操作的主要资源库操作类型是合并。在许多情况下,模型只需要在文件级参与操作。因此,引入了
IStorageMerger
API,从而允许模型提供程序添加合并程序来合并具有特定扩展名或内容类型的文件。但是,在某些情况下,模型可能需要其他上下文才能正确地参与合并。为此,我们引入了 IResourceMappingMerger
和 IMergeContext
API。
合并操作仍由与资源库提供程序相关联的操作触发。但是,一旦用户请求了合并类型的操作,资源库提供程序就需要使模型提供程序参与合并过程,以确保合并操作不会以任何方式破坏模型。
资源库提供程序 API 有两个主要部分与基于模型的合并支持相关。
对于基于模型的合并来说,一个重要方面是用于将所涉及资源的同步状态通知模型提供程序的 API。下列接口用于描述同步状态:
为所有这些接口提供了抽象类,所遵循的约定是类名与除去了“I”前缀的接口名相匹配。资源库提供程序必须覆盖的唯一一个类是 ResourceDiff
类,其目的是提供适当的前文件修订版和后文件修订版。
IMergeContext 接口使用其他支持合并的方法扩展了同步上下文。提供了用于执行下列操作的回调方法:
提供了抽象的 MergeContext 类,这个类包含大多数合并行为的缺省实现,并且还使用 IStorageMerger 来执行三向合并。此外,还提供了一个 SubscriberMergeContext类,这个类用于处理与合并上下文相关联的同步状态描述的填充与维护。
提供了操作类 ModelMergeOperation,这个类使用 IResourceMappingMerger
API
来执行基于模型的合并操作。子类需要覆盖 initializeContext(IProgressMonitor)
方法以返回合并上下文。该操作使用此上下文来尝试执行基于模型的无外设合并。如果发生冲突,则将合并预览工作留给子类处理。正如我们将在下一节看到的那样,有一个 ModelParticipantMergeOperation,它通过使用 ModelSynchronizeParticipant 来提供预览功能。
通过使用 Eclipse 3.2 中引入的公共导航器框架,支持在小组操作中显示逻辑模型。通过使用 org.eclipse.team.ui.teamContentProvider
扩展点,逻辑模型可以使内容扩展与模型提供程序相关联。小组提供程序通过 ITeamContentProviderManager
来访问这些内容提供程序。
在下列几种情况下,小组提供程序可能希望显示逻辑模型:
ModelOperation
类将提供提示,该提示使用已注册的小组内容提供程序来将作用域扩展情况通知用户。ModelSynchronizeParticipant
提供了集成到“同步”视图或任何其他能够显示
iSynchronizePages
的容器的能力。参与者同时使用预先存在的同步参与者功能和公共导航器功能,以允许小组提供程序和模型对工具栏、上下文菜单以及合并预览的其他方面进行定制。ModelSynchronizeParticipant
提供了下列各项:
以下步骤核对表用于为特定小组提供程序定制模型同步参与者:
ModelSynchronizeParticipant
的子类。ISynchronizePageConfiguration.P_VIEWER_ID
设置为上一步骤中指定的查看器标识。MergeActionGroup
的定制子类,从而定制与合并相关的操作的外观。ModelParticipantMergeOperation
的子类,以处理从基于模型的合并过渡到对话框或“同步”视图中的预览。以下 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 以外,还添加了通用文件历史记录视图。这将允许小组提供程序在共享视图中显示其文件/资源历史记录,此外,还允许模型显示那些未直接映射到文件的元素的模型元素历史记录。“历史记录”视图是基于页面的视图,它以下列方式获取所选元素的页面:
RepositoryProvider
适应于 IHistoryPageSource 来获取的。IHistoryPageSource
来获取的。为了支持在用来标识项目与远程内容之间的映射的引用字符串与用于标识向 org.eclipse.core.filesystem.filesystems
扩展点注册的文件系统模式的 URI 之间进行转换,对 ProjectSetCapability
添加了一些方法。小组提供程序可以选择为项目集功能提供支持,以便允许逻辑模型执行远程浏览和项目装入。
小组提供程序可以对模型元素进行修饰,其方法是将模型元素的轻量级修饰符转换为适用于资源映射,并且转换方式与将对象添加项转换为资源映射的方式相同。但是,逻辑模型元素修饰的一个方面存在问题。如果模型元素与资源之间不存在一对一的映射关系,则当底层资源改变时,该模型元素可能无法接收到标签更新。
为了解决此问题,引入了 ITeamStateProvider
,以使模型提供程序能够访问可能会影响小组修饰的状态更改。此外,模型视图还可以使用 SynchronizationStateTester
来确定何时需要更新逻辑模型元素的标签。此 API 依靠
ITeamStateProvider
接口来确定资源的小组状态何时已更改,并且可以作为 IDecorationContext
的组成部分传递给小组修饰符。