在 IBM Rational Application Developer-ClearCase 环境中管理 Utility JAR
 

2009-06-12 作者:Darrell R. Schrag 来源:IBM

 
本文内容包括:
IBM® Rational® Application Developer 和 IBM® Rational® ClearCase® 允许您权衡 Eclipse™ 的能力来帮助您开发复杂的 J2EE 应用软件。有了这些工具,您可以利用 Utility JAR 的优势来提高一个团队环境中正在开发的软件的生产力。

引言

作为一个整合的开发环境 (IDE) 平台,Eclipse (也因此 IBM® Rational® Application Developer) 已经大大提高了您生产工具的能力,从而提高您每天软件开发生产力。然而,Eclipse 本身是使用一个单一用户的思想构建的(请参见 Jazz 项目,这是与一个开发团队的焦点共同构建的开发环境)。您个人的工作空间包括您设计,开发,构建以及测试所需的所有应用软件。如果您需要以一个团队的方式来工作,Rational Application Developer (RAD) 将所有的职责转移到 Eclipse 团队层面上来。

Rational Application Developer 中团队开发的标准起始点是在您的工作空间安装开发所需的资源,然后简单地执行 Team > Share Project 操作。这样就可以让团队层面来接管任务了。也可以这样讲,例如,您已将安装了 ClearCase ,并且已经激活了 ClearCase SCM Adapter。它的功能讲接管此认为,并将指导您将必需的资源从您的工作空间插入到一个 ClearCase 储存库。如果您密切观察您工作空间中的资源,将会很容易发现许多 Java™ 归档 (JAR) 文件。这些 Utility JAR 文件在当今是十分普遍的。然而,Rational Application Developer 给了您许多利用 Utility JAR 文件的方法。

Utility JAR

当今绝大多数 Java 应用软件都采用了大量的 Utility JARs;其中许多开源解决方案都是针对普通问题的。可能这些普通问题之一是将 log4j (http://logging.apache.org/log4j/) 作为一个记录解决方案来使用。如果没有更多的可利用的开源应用软件,已经有几百个种类,而且已经有人针对所需的常用软件提供了一个可执行的方案。这些分析解决方案通常作为 JAR 文件提供。

此外,当今绝大多数组织都试图提供这些开源解决方案的封装框架喝自定义执行,从而简化或者标准化组织对它们使用的方法。这个净工作量需要大多数的 Java™2 Platform,Enterprise Edition (J2EE) 应用软件来执行许多 Utility JAR, 有时执行20、30,或者更多的命令。

有许多使 Utility JARs 包含于您项目的方法,然后使它们包含于您的 Java 构建路径。这篇文章将引导您观看三种方法,然后对它们进行正反两方面的讨论。

方法 1

第一个种利用 Utility JAR 优势的方法是,简单地将它们包含于您的 Web 项目种。您可以使 Utility JAR 包含于 Web-INF\lib地址下的 Web 项目中。要使所有的 JAR 都包含于那个地址下您的构建路径中,可以利用被包含的构建路径存储库, “Web App Libraries”,将这些 JAR 添加到您的 Web 项目构建路径中。图 1描述了 Web 项目的 Web-INF\lib 地址中的 log4j JAR 文件(在左边),以及当您通过 Package Explorer 查看这个项目时它在 Web App Libraries 中是任何显示的。

图 1. 使一个 JAR 文件包含于您的 Web 项目中
导航视图中的 .jar 文件 Package Explorer 中的 .jar 文件

您可以很快感觉到这是多么的实用。表明看来这是十分容易做到的。然而,如果您将它扩展到许多的 Utility JAR 和许多应用软件中,可能有些解决方案会导致一些问题顺其而下。可能会有多种多样包含于单个 EAR (Enterprise Archive)中的 Web 项目。利用这种方法,每个 Web 项目都将包含它自己的 Utility JARs 组合。这将使您的 EAR 文件产生不必要的膨胀。您同时还在没有意识的情况下,产生了将不同版本的 Utility JARs 用在不同 Web 项目中的风险。在性能方面可能会有轻微的差别,而且难于追踪。

方法 2

第二种利用 Utility JAR 优势的方法是,在这个基础上的提高,允许您在一个 EAR 项目中包含 Utility JAR 文件。您可以将 JAR 文件导入到一个 EAR 项目中作为 J2EE Utility JAR。然后这些 JAR 对包含于 EAR 中的任何项目都可以使用,如图 2所示。

图 2. 在 EAR 中包含 JAR
Project Explorer 视图

要将一个 Utility JAR 添加到 EAR 项目中,右键点击部署描述符并选择 Import > J2EE Utility Jar。这个 Import 向导将给您提供许多选项来进行选择。第三个选项允许您拷贝一个额外的 JAR 文件到您的 EAR 项目中,作为一个 Utility JAR,如图 3所示。

图 3. 导入选项
Utility Jar Import 对话框

然后添加一个 EAR Utility JAR 文件到您的 Web 项目的构建路径下,您将利用 Jar Dependency 编辑器来编辑这个 Web 项目的 ...\META-INF\MANIFEST.MF 文件。这里给您提供了一个包含于 EAR 中的 JAR 列表或者模块,这些您可能作为依存关系而使其包含其中,如图 4所示。

图 4. 选择 Classpath 范围和依存关系
JAR Dependency Editor

然后您将在这个构建路径中看到,那些 JAR 文件在“Web App Libraries”条目中,如图 5所示。

图 5. 导入的 JAR 文件
导入的 JAR 文件

这个方案解决了在单一的应用软件中拥有同一个 Utility JAR 的多种拷贝的问题。Web 和 EJB 项目可以利用 MANIFEST.MF Jar Dependency 编辑器,在这个项目构建路径中包含 EAR Utility JAR。此外,在 EAR 的开发和合并中,Rational Application Developer 构建过程包含 Utility JAR。

如果您继续使这些 Utility JAR 包含于每个应用软件,您要在您的版本控制存储库中将这些 JAR 文件一次次地进行分类。对于一个大的组织来说,在整个版本控制系统中,您可能有同一个 Utility JAR 文件的几百个复本。这其实是浪费的存储空间。也有一些构建管理的概念利用这种方法是无法解决的。如果您的组织可以尝试提供所有应用软件应该使用的代表可接受版本或者执行的标准 Utility JAR 捆绑文件,那么您就不能允许这些项目简单地将 JARs 拷贝到他们项目中,否则您将失去控制和管理标准 Utility JARs 的能力。这将由第三种方法来解决。

方法 3

第三种利用 Utility JARs 优势的方法是在一个 EAR 项目中将它们作为链接的资源而导入。您可以再次利用 Import 向导来完成。对于当前这个方法,可以选择第四个选项,即 Create Linked Utility Jars in an existing EAR from an external location,如图 6所示。

图 6. 在这个向导中选择一个不同的导入类型
Utility Jar Import 向导

当您点击 Next 时,您将被询问能够找到 JAR 的一个外部存储单元位置。您还被赋予定义一个 Linked Path Variable的能力,如图 7所示。这个自变量稍后会被用来当作这个外部 JAR 的路径,从而取代了实际的物理路径。

图7. 指定外部路径
指定外部路径

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

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

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

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

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

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

图 10. 为 Linked Resources 指定具体位置
项目资源

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

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

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 组件
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 项目中一个简单的组件,那么您每次创建一个新的视图时都要从这个存储库中取回所有您需要的到您的片段视图根目录下。根据到您存储库的网络链接,这将花费很长的时间。

为 JAR 访问创建一个单独的视图

如果您利用 UCM 项目来为不同的版本创建不同的结构,您将会发现您自己正有规律地在创建新的视图。此外,由于某些原因如果您需要迅速为一个快速生产修复创建一个新视图,大多数时间将会浪费在这个视图的创建中,而不是修复本身。

因此,它将赋予完全创建一个单独视图更多的意义,仅仅是为了访问 Utility JAR 组件。您可以创建一个包含 Utility JAR 只读模式组件的单个 UCM 项目。每个开发人员都将创建一个附带 UCM 项目的视图,如图 12 所示。

图 12. 分离的视图
UCM 组件图

这个视图将被用来取回和操作 Utility JAR 的单一拷贝。由于这个组件是只读模式,您可以自由地重新将这个视图定到任何基线,向前或者向后。这样您可以完全控制您所拥有的 Utility JAR,另一个优势是,无论您的工作设计到多少个项目都只需要一个 Utility JAR 拷贝。

然后您要设置您的 Linked Path Variable,使其指向 Utility JARs 视图中的 Utility JARs 组件,如图 13所示。所有包含您的项目资源的视图都能更快速地被创建,因为它们不包含 Utility JARs。

图13. 设置您的 Linked Path Variable
Utility JAR Import 对话框

结论

Eclipse (也因此为 Rational Application Developer)已经逐渐展示了有价值的工具组合,帮助您构建了复杂的 J2EE 应用软件。然而,由于它的“单个用户”的思想,没有其他人工的介入,您将快速用您的问题管理您的 Utility JAR。然而,稍微考虑一下这个问题,您就可以利用这些 Rational Application Developer 和 ClearCase 提供的特性来为项目团队创建一个简单的方法,从而访问被证实的 Utility JAR 组合。您还可以通过在 ClearCase UCM 组件中管理它们来管理它们的使用。

参考资料

学习 获得产品和技术
  • 在 developerWorks Rational 专区的 Rational Build Forge 产品专题 为构建和发布工程师和经理找到更多的资源,包括文章和白皮书、培训链接、论坛、产品文件和支持。
  • 在 developerWorks Rational 专区的 ClearCase 产品专题 为 ClearCase 用户和管理人员找到更多的资源,包括文章和白皮书、插件、脚本和触发器程序;以及培训链接、论坛、产品文件和支持。
  • ClearQuest 用户和管理人员在 developerWorks Rational 专区的 ClearQuest 产品专题 可以找到更多的资源,包括 ClearQuest hook、Eclipse 插件、产品介绍、文章和白皮书。
  • 下载 IBM 产品评估版本,并掌握来自于 DB2®、Lotus®、Rational®、Tivoli®,以及 WebSphere® 的应用软件开发工具。
讨论

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织