结果 Project Explorer 看起来是一样的，但是 log4j .jar 文件上一个小小的图标表明这个资源是工作空间以外的链接到一个物理层的资源。

    图 8. 项目浏览器中的图标

    利用这个方法，每个开发人员都能够为这个变量提供他们自己的物理路径定义。这样避免了每个开发人员从不得不在他们的桌面上安装准确的相同的物理路径一直到达这个外部位置的过程。这个链接的资源实际上保存在 EAR 的项目文件中。如果您打开这个项目文件，您将看到 Link Path Variable 已经被使用，从而代替了这个实际的物理路径，如图 9所示。

    <locationURI>UTILITY_JARS/log4j-1.2.15.jar</locationURI>

    图 9. 这个项目文件代码中的 Link Path 变量

    Link Path Variable 的定义在您的工作空间参数中被维护。您所有的开发人员将需要确保他们已经定义了这个变量，以及它是指向包含必要 Utility JAR 的一个位置的，如图 10所示：

    图 10. 为 Linked Resources 指定具体位置

    从一个工作空间的角度来看，最终的结果看起来是一样的，所有的行为好像表明 Utility JAR 的物理位置其实是在 EAR 项目中。因此，它预先提供了所提到的好处，好像在您的应用软件中只有一个 Utility JAR 的拷贝。然而，它还修复了保存在整个版本控制存储库的不同地方中，同一个 JAR 文件中多个拷贝的问题。由于这个 Utility JAR 从物理层面看不是保存在 EAR 项目中，因此当您共享这个项目时它们就没有被添加到资源控制中去。

    然后这个问题又变成了“您应该将 Utility JAR 保存在什么位置才能使所有人都可以参考它们呢？”最简单的选择是将它们取出放在一个共享的网络驱动空间。一个相对比较简单的方法是充分利用 ClearCase UCM 优势，同样提供一些 Utility JAR 使用的构建管理。