小组和链接的资源

项目可以包含不是位于本地文件系统中的项目目录中的资源。这些资源称为链接的资源

资源库提供程序的重要性

链接的资源可以对直接对文件系统执行操作的资源库提供程序提出特定问题。这是因为在文件系统中,链接的资源在设计上不存在于直接的项目目录树中。

具有下列特征的提供程序可能会受到链接的资源的影响:

  1. 调出到外部程序,然后该外部程序直接对文件系统执行操作的那些提供程序。
  2. 利用 IResource 实现但是假定项目中的所有文件/文件夹都作为单个具有根目录的目录树的直接后代存在的那些提供程序。

在第一种情况下,假定用户选择链接的资源,并尝试对它执行提供程序操作。由于提供程序调用命令行客户机,所以可以假定提供程序执行等价于先前调用 IResource.getLocation().toOSString(),并将获得的文件系统位置作为自变量提供给命令行程序的某些操作。如果所讨论的资源是链接的资源,则这将在项目目录树外部产生文件/文件夹。并不是所有命令行客户机都能预料和能够处理这种情况。总之,如果提供程序曾经获得了资源的文件系统位置,则可能需要执行额外的工作来处理链接的资源。

第二种情况相当类似,因为隐式假定项目资源的结构与文件系统文件/文件夹的结构是一一对应的关系。通常,如果提供程序将 IResource 操作与 java.io.File 操作混合在一起,则它们可能会遇到麻烦。例如,对于链接,IFile 的父代与 java.io.File 的父代不同,而假定它们相同的那些代码将失败。

向下兼容

链接的资源的引入不会无意识地损坏现有提供程序是非常重要的。更准确地说,提供程序应注意合理地假定本地文件系统结构反映了项目结构。因此,缺省情况下,不能将链接的资源添加至映射至此类提供程序的项目。另外,缺省情况下,不能与该提供程序共享包含链接的资源的项目。

用于处理链接的资源的战略

为了能够“顺利链接”,提供程序应当允许对具有链接的资源的项目进行版本控制,但是可以不允许对链接的资源本身进行版本控制。

一个相当复杂的解决方案是允许对实际的链接的资源进行版本化,但是不提倡这种方法,原因是它会产生复杂的方案(例如,可能已在另一个项目树中由另一个提供程序对文件进行了版本控制)。因此,我们建议支持包含未进行版本控制的链接的资源的进行了版本控制的项目。

关于“顺利链接”的技术详细信息

可以通过覆盖 RepositoryProvider.canHandleLinkedResources() 方法以返回 true 来升级资源库提供程序实现以支持链接的资源。一旦执行了此操作,就会允许链接的资源存在于与该资源库提供程序共享的项目中。但是,资源库提供程序必须执行一些步骤来确保正确处理了链接的资源。如上所述,强烈建议资源库提供程序忽略所有链接的资源。这意味着应当从资源库提供程序支持的操作中排除链接的资源(及其子代)。而且,如果资源库提供程序实现覆盖了缺省 IMoveDeleteHook,则资源库提供程序应当将缺省的移动和删除行为用于链接的资源。

小组提供程序可以使用 IResource.isLinked() 来确定是否是链接的资源。但是,此方法仅对链接的根才返回 true。以下代码段可以用来确定资源是否是链接的子代。

String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();

资源库提供程序应当忽略将以上代码对其求值为 true 的任何资源。

Copyright IBM Corporation and others 2000, 2003.