企业应用级别的Ant模组编译环境 (2)

很有效的方法。我们需要一个好的分而治之（divide-and-conquer）的技术来帮助我们来管理大量的源码。在编译环境中创建编译模块是个好方法。

我们通过在应用程序的根目录下创建一个目录来创建一个模块。这个新的目录成为这个模块的基础。在每个模块目录下，我们存放与其相关的文件和源码。

这是一个示例程序的编译环境，按照模块来组织：

appname/
|-- admin/
|-- core/
|-- db/
|-- lib/
|-- ordermgt/
|-- reports/
|-- web/
|-- build.xml

下面是每个节点的含义：

? 除了lib/ 以外的每个目录都是一个模块。在这个例子中，admin模块提供了POJO的实现，它容许某人来管理应用（例如，创建用户，授权等等）。同样的，reports模块中，有能够产生报告的组件的实现。而core 模块中是那些在很多或全部模块中都用到的组件，它们不是真正地和系统的某个功能相联系。（例如，StringUtil 类）通常，其他地所有模块都会依赖核心（core）模块。

其他模块与admin, reports, 及core模块一样：他们有着各自的自包含的系统功能，并与其他模块区别开来。此外，由于我们的范例应用可以支持基于web的交互，我们还可以有一个web模块，包含了用以创建一个.war文件所需要的一切内容。

? lib/ 目录比较特殊。它含有应用程序编译或运行所需地所有第三方.jars文件。我们把其他模块所需的所有第三方.jars文件放在这个目录中，而不是它们自己的模块中。原因如下：

1. 在一个地方更便于管理对第三方的依赖（third-party dependencies）。可以在一个模块的build.xml 文件中，利用Ant的<path> 语句来定义改模块是否使用这些库文件。

2. 通过排除重复.jars文件的可能性，从而避免了装载类或API的版本冲突。如果有不止一个模块使用了一个负责存储commons-logging.jar文件的Jakarta Commons Logging模块，会发生什么情况？假设每个模块都持有Jakarta Commons Logging模块的备份，这样就会有一个潜在的问题?D?D一个模块所持有的备份和另外一个模块所持有的版本不同。当应用程序开始运行，只有第一个在classpath上找到的.jar文件被载入以满足所需，这就潜在地引起了与其他模块的冲突。我们通过在根目录下只持有一个.jar文件来避免这种冲突。

3. 对第三方的依赖随你的源码改变版本。浏览很多项目，会发现，这是你想把你所依赖的库文件放在CVS上的最重要原因。通过这样做，你能确保，无论你从CVS上导出的是那个版本或那个分支的软件，你都能找到第三方类库的合适版本来支持你的软件的特定版本。

? 根build.xml 文件是主要的管理文件。它知道为了编译每个模块，什么文件和目标（target：译者注，应该是<target>，是Ant中的一个语句）是必须的。然后，由模块来保证这些物件（artifact）被正确的编译。

例如，假设一个项目正在编译，现在是编译ordermgt 模块的时候了，根编译文件（root build file）应该知道，去调用ordermgt/build.xml 文件中一个Ant任务来完成这编译。而ordermgt/build.xml 文件应该确切的知道要编译生成ordermgt .jar 文件需要些什么。而且，如果整个项目被编译并合并入一个.ear文件，这个根build.xml 文件应该知道如何去构建。

根build.xml 文件是怎么知道要去编译一个模块并且以何种顺序来编译的呢？下面是一个Ant XML文件的一部分，它显示了build.xml文件是如何完成设定的目标的：

<!-- =========================================　　 Template target.　Never called explicitly,　　　only used to pass calls to underlying　　　children modules.　　 ======================================