ANT的基本概念：Java的Makefile
当一个代码项目大了以后，每次重新编译，打包，测试等都会变得非常复杂而且重复，因此c语言中有make脚本来帮助这些工作的批量完成。在Java中应用是平台无关性的，当然不会用平台相关的make脚本来完成这些批处理任务了，ANT本身就是这样一个流程脚本引擎，用于自动化调用程序完成项目的编译，打包，测试等。除了基于JAVA是平台无关的外，脚本的格式是基于XML的，比make脚本来说还要好维护一些。
每个ant脚本（缺省叫build.xml）中设置了一系列任务(target)：比如对于一个一般的项目可能需要有以下任务。
任务1：usage 打印本脚本的帮助信息（缺省）
任务2：
任务3：
javadoc <-- build <-- init 生成JAVADOC
| 任务4：
jar <-- build <-- init 生成JAR
|
任务5：
all <-- jar + javadoc <-- build <-- init
|
完成以上所有任务：
而多个任务之间往往又包含了一定了依赖关系：比如把整个应用打包任务(jar)的这个依赖于编译任务(build)，而编译任务又依赖于整个环境初始化任务(init)等。
注：我看到很多项目的ant脚本中的命名基本上都是一致的，比如：编译一般叫build或者compile；打包一般叫jar或war；生成文档一般命名为javadoc或javadocs；执行全部任务all。在每个任务的中，ANT会根据配置调用一些外部应用并配以相应参数执行。虽然ANT可调用的外部应用种类非常丰富，但其实最常用的就2，3个：比如javac javadoc jar等。 ANT的安装
解包后在系统可执行路径中加入指向ant的bin的路径就可以了，比如可以在GNU/Linux上把以下配置加入/etc/profile中：
export ANT_HOME=/home/ant
export JAVA_HOME=/usr/java/j2sdk1.4.1
export PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin
|
这样执行ant后，如果不指定配置文件ant会缺省找build.xml这个配置文件，并根据配置文件执行任务，缺省的任务设置可以指向最常用的任务，比如：build，或指向打印帮助信息：usage，告诉用户有那些脚本选项可以使用。
ANT的使用
最好的学习过程就是看懂那些open source项目中的build.xml脚本，然后根据自己的需要简化成一个更简单的，ANT和APACHE上很多非常工程派的项目：简单易用，而且适应性非常强，因为这些项目的建立往往来源于开发人员日常最直接的需求。
以下是的一个WebLucene应用的例子：修改自JDOM的build.xml：
<project default="usage" basedir=".">
<!-- ====================== -->
<!-- Initialization target -->
<!-- ====================== -->
<target name="init">
<tstamp/>
<property file="${basedir}
/build.properties" />
<property name="Name"
value="ProjectFullName"/>
<property name="name"
value="project_name"/>
<property name="version"
value="0.2"/>
<property name="year"
value="2003"/>
<echo message="-----------
${Name} ${version} [${year}]
------------"/>
<property name="debug"
value="off"/>
<property name="optimize"
value="on"/>
<property name="deprecation"
value="on"/>
<property name="src.dir"
value="./src/WEB-INF/src"/>
<property name="lib.dir"
value="./src/WEB-INF/lib"/>
<property name="packages" value="com.chedong.*,org.apache.lucene.*"/>
<property name="build.src"
value="./src/WEB-INF/build"/>
<property name="build.dest"
value="./src/WEB-INF/classes"/>
<property name="build.javadocs"
value="./src/doc"/>
<path id="classpath">
<pathelement path="${jsdk_jar}"/>
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
</path>
<filter token="year"
value="${year}"/>
<filter token="version"
value="${version}"/>
<filter token="date"
value="${TODAY}"/>
<filter token="log"
value="true"/>
<filter token="verbose"
value="true"/>
</target>
<!-- ================== -->
<!-- Help on usage -->
<!-- ================== -->
<target name="usage" depends="init">
<echo message="${Name} Build file"/>
<echo message="----------"/>
<echo message=""/>
<echo message=" available targets are:"/>
<echo message=""/>
<echo message=" jar
--> generates the ${name}.jar file"/>
<echo message=" build
--> compiles the source code"/>
<echo message=" javadoc
--> generates the API documentation"/>
<echo message=" clean
--> cleans up the directory"/>
<echo message=""/>
<echo message=" Please rename
build.properties.default to build.properties"/>
<echo message=" and edit
build.properties to specify JSDK 2.3 classpath."/>
<echo message=""/>
<echo message=" See the comments
inside the build.xml file for more details."/>
<echo message="--------------"/>
<echo message=""/>
<echo message=""/>
</target>
<!-- ===================== -->
<!-- Prepares the source code -->
<!-- ===================== -->
<target name="prepare-src"
depends="init">
<!-- create directories -->
<mkdir dir="${build.src}"/>
<mkdir dir="${build.dest}"/>
<!-- copy src files -->
<copy todir="${build.src}">
<fileset dir="${src.dir}"/>
</copy>
</target>
<!-- ===================== -->
<!-- Compiles the source directory -->
<!-- ===================== -->
<target name="build" depends="prepare-src">
<javac srcdir="${build.src}"
destdir="${build.dest}"
debug="${debug}"
optimize="${optimize}">
<classpath refid="classpath"/>
</javac>
</target>
<!-- ==================== -->
<!-- Creates the class package -->
<!-- ==================== -->
<target name="jar" depends="build">
<jar jarfile="${lib.dir}/${name}.jar"
basedir="${build.dest}"
includes="**"/>
</target>
<!-- ==================== -->
<!-- Creates the API documentation -->
<!-- ==================== -->
<target name="javadoc" depends="build">
<mkdir dir="${build.javadocs}"/>
<javadoc packagenames="${packages}"
sourcepath="${build.src}"
destdir="${build.javadocs}"
author="true"
version="true"
use="true"
splitindex="true"
windowtitle="${Name} API"
doctitle="${Name}">
<classpath refid="classpath"/>
</javadoc>
</target>
<!-- ======================= -->
<!-- Clean targets -->
<!-- ======================= -->
<target name="clean" depends="init">
<delete dir="${build.src}"/>
<delete dir="${build.dest}/org"/>
<delete dir="${build.dest}/com"/>
<delete>
<fileset dir="${build.dest}"
includes="**/*.class"/>
</delete>
</target>
</project>
<!-- End of file -->
|
缺省任务：usage 打印帮助文档，告诉有那些任务选项：可用的有build, jar, javadoc和clean。
初始化环境变量：init
所有任务都基于一些基本环境变量的设置初始化完成，是后续其他任务的基础，在环境初始化过程中，有2点比较可以方便设置：
1、除了使用却缺省的property设置了JAVA源路径和输出路径外，引用了一个外部的build.properties文件中的设置：
<property file="${basedir}
/build.properties" />
|
这样大部分简单配置用户只要会看懂build.properties就可以了，毕竟XML比起key value的属性文件还是要可读性差一些。用build.properties也可以方便其他用户从编译的细节中解放出来。
2、CLASSPATH设置：使用了其中的：
<path id="classpath">
<pathelement path="${jsdk_jar}"/>
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
</path>
|
则相当于设置了：
CLASSPATH=/path/to/resin/lib/jsdk23.jar;
/path/to/project/lib/*.jar;
|
文件复制：prepare-src
创建临时SRC存放目录和输出目录。
<!-- ============ -->
<!-- Prepares the source code -->
<!-- ========== -->
<target name="prepare-src"
depends="init">
<!-- create directories -->
<mkdir dir="${build.src}"/>
<mkdir dir="${build.dest}"/>
<!-- copy src files -->
<copy todir="${build.src}">
<fileset dir="${src.dir}"/>
</copy>
</target>
|
编译任务：build
编译时的CLASSPATH环境通过一下方式找到引用一个path对象
<classpath refid="classpath"/>
|
打包任务：jar
对应用打包生成项目所写名的.jar文件
<!-- ============== -->
<!-- Creates the class package -->
<!-- ============ -->
<target name="jar" depends="build">
<jar jarfile="${lib.dir}/${name}.jar"
basedir="${build.dest}"
includes="**"/>
</target>
|
生成JAVADOC文档任务: javadoc
<!-- ================ -->
<!-- Creates the API documentation -->
<!-- ============== -->
<target name="javadoc" depends="build">
<mkdir dir="${build.javadocs}"/>
<javadoc packagenames="${packages}"
sourcepath="${build.src}"
destdir="${build.javadocs}"
author="true"
version="true"
use="true"
splitindex="true"
windowtitle="${Name} API"
doctitle="${Name}">
<classpath refid="classpath"/>
</javadoc>
</target>
|
清空临时编译文件：clean
<!-- ============= -->
<!-- Clean targets -->
<!-- =========== -->
<target name="clean" depends="init">
<delete dir="${build.src}"/>
<delete dir="${build.dest}/org"/>
<delete dir="${build.dest}/com"/>
<delete>
<fileset dir="${build.dest}"
includes="**/*.class"/>
</delete>
</target>
|
8. 定义恰当的任务参数关系
假设dist任务从属于jar任务，那么哪个任务从属于compile任务，哪个任务从属于prepare任务呢？Ant构建文件最终定义了任务的从属关系图，它必须被仔细地定义和维护。 应该定期检查任务的从属关系以保证构建工作得到正确执行。大的构建文件随着时间推移趋向于增加更多的任务，所以到最后由于不必要的从属关系导致构建工作非常困难。比如，你可能发现在程序员只是需要编译一些没有使用EJB的GUI代码时，重新生成EJB代码。 以“优化”的名义忽略任务的从属关系是另一种常见的错误。这种错误迫使程序员为了得到恰当的结果必须记住并按照特定的顺序调用一串任务。更好的做法是：提供描述清晰的公共任务，这些任务包含正确的任务从属关系；另外提供一套“专家”任务让你能够手工执行个别的构建步骤，这些任务不提供完整的构建过程，但是让那些专家在快速而恼人的编码期间跳过某些步骤。
9.使用配置属性
任何需要配置或可能发生变化的信息都应作为Ant属性定义下来。对于在构建文件中多次出现的值也同样处理。属性既可以在构建文件头部定义，也可以为了更好的灵活性而在单独的属性文件中定义。以下是在构建文件中定义属性的样式：
<project name="sample" default="compile" basedir=".">
<property name="dir.build" value="build"/>
<property name="dir.src" value="src"/>
<property name="jdom.home" value="../java-tools/jdom-b8"/>
<property name="jdom.jar" value="jdom.jar"/>
<property name="jdom.jar.withpath"
value="${jdom.home}/build/${jdom.jar}"/>
etc...
</project>
|
或者你可以使用属性文件：
<project name="sample" default="compile" basedir=".">
<property file="sample.properties"/>
etc...
</project>
|
在属性文件 sample.properties中:
dir.build=build
dir.src=src
jdom.home=../java-tools/jdom-b8
jdom.jar=jdom.jar
jdom.jar.withpath=${jdom.home}/build/${jdom.jar}
| 用一个独立的文件定义属性是有好处的，它可以清晰地定义构建中的可配置部分。另外，在开发者工作在不同操作系统的情况下，你可以在不同的平台上提供该文件的不同版本。
10. 保持构建过程独立 为了最大限度的扩展性，不要应用外部路径和库文件。最重要的是不要依赖于程序员的CLASSPATH设置。取而代之的是，在构建文件中使用相对路径并定义自己的路径。如果你引用了绝对路径如C:\java\tools，其他开发者未必使用与你相同的目录结构，所以就无法使用你的构建文件 如果你部署开发源码项目，应该提供包括所有需要的JAR文件的发行版本，当然是在遵守许可协议的基础上。对于内部项目，相关的JAR文件都应在版本控制系统的管理中，并捡出到大家都知道的位置。 当你不得不应用外部路径时，应将路径定义为属性。使程序员能够涌适合他们自己的机器的参数重载这些属性。你也可以使用以下语法引用环境变量：
<property environment="env"/>
<property name="dir.jboss" value="${env.JBOSS_HOME}"/>
|
11. 使用版本控制系统 构建文件是一个重要的文件，应该象代码一样进行版本控制。当你标记你的代码时，也应用同样的标签标记构建文件。这样当你需要回溯构建旧版本的软件时，能够使用相对应的旧版本构建文件。 除构建文件之外，你还应在版本控制中维护第三方JAR文件。同样，这使你能够重新构建旧版本的软件。这也能够更容易保证所有开发者拥有一致的JAR文件，因为他们都是同构建文件一起从版本控制系统中捡出的。 通常应避免在版本控制系统中存放构建输出品。倘若你的源代码很好地得到了版本控制，那么通过构建过程你能够重新生成任何版本的产品。
12. 把Ant作为“最小公分母”
假设你的开发团队使用IDE，为什么要为程序员通过点击图标就能够构建整个应用而烦恼呢？ IDE的问题在团队中是一个关于一致性和重现性的问题。几乎所有的IDE设计初衷都是为了提高程序员的个人生产率，而不是开发团队的持续构建。典型的IDE要求每个程序员定义自己的项目文件。程序员可能拥有不同的目录结构，可能使用不同版本的库文件，还可能工作在不同的平台上。这将导致出现这种情况：在A那里运行良好的代码，到B那里就无法运行。 不管你的开发团队使用何种IDE，一定要建立所有程序员都能够使用的Ant构建文件。要建立一个程序员在将新代码提交版本控制系统前必须执行Ant构建文件的规则。这将确保代码是经过同一个Ant构建文件构建的。当出现问题时，要使用项目标准的Ant构建文件，而不是通过某个IDE来执行一个干净的构建。
程序员可以自由选择任何他们习惯使用的IDE。但是Ant应作为公共基线以保证永远是可构建的。
13. 使用 zipfileset属性
人们经常使用Ant产生WAR、JAR、ZIP和 EAR文件。这些文件通常都要求有一个特定的内部目录结构，但其往往与你的源代码和编译环境的目录结构不匹配。 一个最常用的方法是写一个Ant任务按照期望的目录结构把一大堆文件拷贝到临时目录中，然后生成压缩文件。这不是最有效的方法。使用zipfileset属性是更好的解决方案。它让你从任何位置选择文件，然后把它们按照不同目录结构放进压缩文件中。以下是一个例子：
<ear earfile="${dir.dist.server}/payroll.ear"
appxml="${dir.resources}/application.xml">
<fileset dir="${dir.build}" includes="commonServer.jar"/>
<fileset dir="${dir.build}">
<include name="payroll-ejb.jar"/>
</fileset>
<zipfileset dir="${dir.build}" prefix="lib">
<include name="hr.jar"/>
<include name="billing.jar"/>
</zipfileset>
<fileset dir=".">
<include name="lib/jdom.jar"/>
<include name="lib/log4j.jar"/>
<include name="lib/ojdbc14.jar"/>
</fileset>
<zipfileset dir="${dir.generated.src}" prefix="META-INF">
<include name="jboss-app.xml"/>
</zipfileset>
</ear>
| 在这个例子中，所有JAR文件都放在EAR文件包的lib目录中。hr.jar和billing.jar是从构建目录拷贝过来的。因此我们使用zipfileset属性把它们移动到EAR文件包内部的lib目录。prefix属性指定了其在EAR文件中的目标路径。
14. 运行 Clean 构建任务的测试
假设你的构建文件中有clean和compile的任务，执行以下的测试。第一步，执行ant clean；第二步，执行ant compile；第三步，再执行ant compile。第三步应该不作任何事情。如果文件再次被编译，说明你的构建文件有问题。 构建文件应该只在与输出文件相关联的输入文件发生变化时，才应该执行任务。一个构建文件在不必执行诸如编译、拷贝或其他工作任务的时候执行这些等任务是低效的。当项目规模增长时，即使是小的低效工作也会成为大的问题。
15. Avoid Platform-Specific Ant Wrappers
不管什么原因，有人喜欢用简单的、名称叫做compile之类的批文件或脚本装载他们的产品。当你去看脚本的内容，你会发现以下内容：
ant compile
其实开发人员熟悉Ant，并且完全能够自己键入ant compile。请不要仅仅为了调用Ant而使用特定平台的脚本。这只会使其他人在首次使用你的脚本时，增加学习和理解的烦扰。除此之外，你不可能提供适用于每个操作系统的脚本，这是真正烦扰其他用户的地方。
总结 太多的公司依靠手工方法和程序来编译代码和生成软件发布版本。那些不使用Ant或类似工具定义构建过程的开发团队，花费了令人惊异的时间来捕捉代码编译过程中出现的问题，这些在某些开发者那里编译成功的代码，到另一些开发者那里却失败了。
生成并维护构建脚本不是一项迷人的工作，但却是一项必需的工作。一个好的Ant构建文件将使你集中到更喜欢的工作——写代码中！
参考
· Ant
· AntGraph: Ant依赖性的可视化工具
· Ant: The Definitive Guide, O'Reilly
· Java Extreme Programming Cookbook, O'Reilly |
| 
