企业应用级别的Ant模组编译环境[4]

下面是每个节点的含义

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

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

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

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

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

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

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

[] [] [] [] []