Utility JAR 管理

    ClearCase UCM 提供了一个简单而有效的方法来管理 Utility JAR 的使用。如果一个组织拥有一个中心团队，能够负责提供开源解决方案使用的指导，同时可能提供每个应用软件都要使用的组织框架，那么就可以获得一种很理想的将前面所描述的资源技巧和 ClearCase UCM 只读部分的使用联合起来的方法。这里讲述了您如何可以做到。

    版本管理

    这个中心团队应该创建和维护应用软件团队使用的用来部署可接受 Utility JAR 文件版本的 UCM 组件。JAR 每个 JAR 捆装文件都应该定制基线来区分 Utility JARs 的不同版本。由于每个团队都为他们的工作创建了 UCM 项目，它们应该包含这个组件作为他们 UCM 项目的一个只读组件。这个组件的路径穿过他们的视图，然后变成用来参考链接的 Utility JAR 的 Linked Path Variable 的物理定义，如图 11所示。

    图 11. 控制版本的 UCM 组件

    这就是映射在这个文件系统上视图所呈现的情形，例如，Z 驱动器：

    资源代码文件系统的样本视图

Z:\MyVOB\ProjectComponent\MyProject
                         \MyProjectEJB
                         \MyProjectWeb
        \UtilityJarComponent\UtilityJars\log4j.jar
                                        \struts.jar

    因此，UTILITY_JAR Link Path 变量应该被定义为 Z:\MyVOB\UtilityJarComponent\UtilityJars\。如果另一个开发人员将视图映射在X: 驱动器，这个人将获得她自己的变量定义。这种方法允许中心 Utility JAR 团队管理那个组件。每个项目都可能包含那个组件，但是只能是只读模式。这样增强了 Utility JAR 生产－消费模式，并迫使项目变成用户。

    您可以再次检查这个方案给予您的所有利益。您只获得了一个应用软件中一个 Utility JAR 拷贝的利益。您还获得了不用对物理上存在于 EAR 项目中 Utility JAR 文件进行分类的利益，这将节省储存库空间。您还取得了某种层面上对 Utility JAR 的管理权，因为一个中心团队可以管理 Utility JAR 组件的内容。然后每个项目通过利用 Linked Path 变量来使用那个组件。

    然而，还有更多您需要考虑的情景。如果当您拥有大量 Utility JAR，需要从一个存储库中创建一个片段视图时，要跑半个地球会是什么样情况呢？如果这些 Utility JAR 只是您的 UCM 项目中一个简单的组件，那么您每次创建一个新的视图时都要从这个存储库中取回所有您需要的到您的片段视图根目录下。根据到您存储库的网络链接，这将花费很长的时间。