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

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

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

<! ========================================= Template targetNever called explicitlyonly used to pass calls to underlyingchildren modules ========================================= > <target name=template depends=init>< Define the modules and the order in which they are executed for any given targetThis means _order matters_Any dependencies that are to be satisfied byone module for another must be declared in the order the dependencies occur ><echo>Executing ${target} \target for the core module…</echo><ant target=${target} dir=core/><echo>Executing ${target} \target for the admin module…</echo><ant target=${target} dir=admin/>…</target>

无论根buildxml 文件调用了哪个编译目标都由这个template 目标负责以一定的顺序传递给相应的子模块例如如果我们想要清理整个工程我们应该只需在工程的根部调用clean 目标即可然后下面的任务将被执行

<! ========================================= Clean all modules ========================================= ><target name=clean depends=init><echo>Cleaning all builds</echo><antcall target=template><param name=target value=clean/></antcall></target>

根buildxml 文件通过直接调用template 目标来间接地实现调用clean 目标从而保证了所有模块都被清理

上面的模块组织和相关的编译目标真地使管理源码和编译变得更容易了这种结构有助于你更快更容易地找到你想要的源码而template 目标负责管理任务是如何执行的

但模块结构最精彩的部分是这里

在完成了整个工程的完整编译后可以对任何模块进行独立的编译只要在命令行中切换到该模块目录下并执行

> ant target

[] [] [] [] []