在Ant出现之前构建和部署Java应用需要使用包括特定平台的脚本Make文件各种版本的IDE甚至手工操作的大杂烩现在几乎所有的开源Java项目都在使用Ant大多数公司的内部项目也在使用AntAnt在这些项目中的广泛使用自然导致了读者对一整套Ant最佳实践的迫切需求
本文总结了我喜爱的Ant技巧或最佳实践多数是从我亲身经历的项目错误或我听说的其他人经历的 恐怖故事中得到灵感的比如有人告诉我有个项目把XDoclet 生成的代码放入带有锁定文件功能的版本控制工具中
当开发者修改源代码时他必须记住手工检出（Check out）并锁定所有将要重新生成的文件然后手工运行代码生成器只到这时他才能够让Ant编译代码这一方法还存在如下一些问题
生成的代码无法存储在版本控制系统中Ant（本案例中是Xdoclet）应该自动确定下一次构建涉及的源文件而不应由程序员手工确定
Ant的构建文件应该定义好正确的任务依赖关系这样程序员就不必为了完成构建而不得不按照特定顺序调用任务
当我开始一个新项目时我首先编写Ant构建文件Ant文件明确地定义构建的过程并被团队中的每个程序员使用本文所列的技巧基于这样的假定Ant构建文件是一个必须仔细编写的重要文件它应在版本控制系统中得到维护并被定期进行重构下面是我的十五大Ant最佳实践
采用一致的编码规范
Ant用户有的喜欢有的痛恨其构建文件的XML语法与其跳进这一令人迷惑的争论中不如让我们先看一些能保持XML构建文件简洁的方法
首先也是最重要的花费时间格式化你的XML让它看上去很清晰不论XML是否美观Ant都可以工作但是丑陋的XML很难令人读懂倘若你在任务之间留出空行有规则的缩进每行文字不超过列左右那么XML令人惊讶地易读再加上使用能够高亮XML语法的优秀编辑器或IDE工具你就不会有阅读的麻烦
同样精选含意明确容易读懂的词汇来命名任务和属性比如dirreports就比rpts好特定的编码规范并不重要只要拿出一套规范并坚持使用就行
将buildxml放在项目根目录中
Ant构建文件buildxml可以放在任何位置但是放在项目顶级目录中可以保持项目简洁这是最常用的规范开发者能够在顶级目录中找到预期的buildxml把构建文件放在根目录中也能够使人容易了解项目目录树中不同目录之间的逻辑关系以下是一个典型的项目目录层次
[root dir]
| buildxml
+src
+lib (包含第三方 JAR包)
+build (由 build任务生成)
+dist (由 build任务生成)
当buildxml在顶级目录时假设你处于项目某个子目录中只要输入ant find compile 命令不需要改变工作目录就能够以命令行方式编译代码参数find告诉Ant寻找存在于上级目录中的buildxml并执行
使用单一的构建文件
有人喜欢将一个大项目分解成几个小的构建文件每个构建文件分担整个构建过程的一小部分工作这确实是看法不同的问题但是应该认识到将构建文件分割会增加对整体构建过程的理解难度要注意在单一构建文件能够清楚表现构建层次的情况下不要过工程化(overengineer)
即使你把项目划分为多个构建文件也应使程序员能够在项目根目录下找到核心buildxml尽管该文件只是将实际构建工作委派给下级构建文件也应保证该文件可用
提供良好的帮助说明
应尽量使构建文件自文档化增加任务描述是最简单的方法当你输入ant projecthelp时你就可以看到带有描述的任务清单比如你可以这样定义任务
<target name=compile
description=Compiles code
output goes to the build dir>
最简单的规则是把所有你想让程序员通过命令行就可以调用的任务都加上描述对于一般用来执行中间处理过程的内部任务比如生成代码或建立输出目录等就无法使用描述属性
这时可以通过在构建文件中加入XML注释来处理或者专门定义一个help任务当程序员输入ant help时来显示详细的使用说明
<target name=help
description=Display detailed usage information>
<echo>Detailed help
</echo></target>
提供清除任务
每个构建文件都应包含一个清除任务用来删除所有生成的文件和目录使系统回到构建文件执行前的初始状态执行清空任务后还存在的文件都应处在版本控制系统的管理之下比如
<target name=clean
description=Destroys all
generated files and dirs>
<delete dir=${dirbuild}/>
<delete dir=${dirdist}/>
</target>
除非是在产生整个系统版本的特殊任务中否则不要自动调用clean任务当程序员仅仅执行编译任务或其他任务时他们不需要构建文件事先执行既令人讨厌又没有必要的清空任务要相信程序员能够确定何时需要清空所有文件
使用ANT管理任务从属关系
假设你的应用由Swing GUI组件Web界面EJB层和公共应用代码组成在大型系统中你需要清晰地定义每个Java包属于系统的哪一层否则任何一点修改都要被迫重新编译成百上千个文件糟糕的任务从属关系管理会导致过度复杂而脆弱的系统改变GUI面板的设计不应造成Servlet和EJB的重编译
当系统变得庞大后稍不注意就可能将依赖于客户端的代码引入到服务端这是因为典型的IDE项目文件编译任何文件都使用单一的classpath而Ant能让你更有效地控制构建活动
设计你的Ant构建文件编译大型项目的步骤首先编译公共应用代码将编译结果打成JAR包文件然后编译上一层的项目代码编译时依靠第一步产生的JAR文件不断重复这一过程直到最高层的代码编译完成
分步构建强化了任务从属关系管理如果你工作在底层Java框架上偶然引用到高层的GUI模板组件这时代码不需要编译这是由于构建文件在编译底层框架时在源路径中没有包含高层GUI面板组件的代码
定义并重用文件路径
如果文件路径在一个地方一次性集中定义并在整个构建文件中得到重用那么构建文件更易于理解以下是这样做的一个例子
<project name=sample
default=compile basedir=>
<path id=mon>
<pathelement
location=${jdomjarwithpath}/>
etc</path>
<path id=classpathclient>
<pathelement location=
${guistuffjarwithpath}/>
<pathelement location=
${anotherjarwithpath}/>
<! reuse the common classpath >
<path refid=mon/>
</path>
<target name=mon
depends=prepare>
<javac destdir=${dirbuild}
srcdir=${dirsrc}>
<classpath
refid=mon/>
<include
name=com/oreilly/common/**/>
</javac>
</target>
</project>
当项目不断增长构建日益复杂时这一技术越发体现出其价值你可能需要为编译不同层次的应用定义各自的文件路径比如运行单元测试的运行应用程序的运行Xdoclet的生成JavaDocs的等等不同路径
这种组件化路径定义的方法比为每个任务单独定义路径要优越得多否则很容易丢失任务从属关系的轨迹
定义恰当的任务从属关系
假设dist任务从属于jar任务那么哪个任务从属于compile任务哪个任务从属于prepare任务呢？Ant构建文件最终定义了任务的从属关系图它必须被仔细地定义和维护
应该定期检查任务的从属关系以保证构建工作得到正确执行大的构建文件随着时间推移趋向于增加更多的任务所以到最后可能由于不必要的从属关系导致构建工作非常困难比如你可能发现在程序员只需编译一些没有使用EJB的GUI代码时又重新生成了EJB代码
以优化的名义忽略任务的从属关系是另一种常见的错误这种错误迫使程序员为了得到恰当的结果必须记住并按照特定的顺序调用一串任务更好的做法是提供描述清晰的公共任务这些任务包含正确的任务从属关系另外提供一套专家任务让你能够手工执行个别的构建步骤这些任务不提供完整的构建过程但是让那些专家用户在快速而恼人的编码期间能够跳过某些步骤
使用属性
任何需要配置或可能发生变化的信息都应作为Ant属性定义下来对于在构建文件中多次出现的值也同样处理属性既可以在构建文件头部定义也可以为了更好的灵活性而在单独的属性文件中定义以下是在构建文件中定义属性的样式
<project name=sample
default=compile basedir=>
<property name=dirbuild
value=build/>
<property name=dirsrc
value=src/>
<property name=jdomhome
value=/javatools/jdomb/>
<property name=jdomjar
value=jdomjar/>
<
