Build.xml文件采用了非普通的技巧，其中的一个目标是防止开发人员对每一次的编译指定发布信息。绝大部分的编译并非都需要发布，为了给每一测试编译提供一个发布名称，开发人员将通过使用一个固定的Build标识符的值来对他们的Builds过程进行脚本化。
为了达到这一目的，我们将对象分离以建立类和任何的JARs。名为classes的类首先将其srcdir属性设置为前一个定义好的sources属性值，然后，当classes对象直接运行，使用编辑的Java sources文件将可以在scr目录中查找到。开发人员编写的源代码在被编译之前，允许使用IDE和其他程序，这就能够从编译错误信息中提取文件名然后可以在编辑程序中得以纠正。
然而，当sources文件被编译为包含在一个JAR的类时，我们不会将这些类编译在scr目录中。相反，我们必须复制这些文件，然后执行符号替代。源代码目录的建立和声明都在pre-jar目标中执行。
然后，pre-jar目标从scr目录中复制源代码层次到jar目录之下。在复制过程中，一个过滤器通过release属性的值取代字符@RELEASE@的所有具体值。在pre-jar对象中设置过滤源目录之后，classes对象将设置srcdir的值。幸运的是，Ant的不允许属性重新定义的规则防止了设置的值不会被覆盖。
pre-jar目标处理过滤过程，但它无法保证用于@RELEASE@替代符号的release属性一定具有一个赋予值。这一过程可以通过ensure-release目标来检查，如果没有赋予值，就会跳出一个失败信息以说明如何指定一个发布标识符。
集中
pre-jar和ensure-release目标能够自动地被相关jar目标处理。尤其是jar目标确保它的任务被处理之前，pre-jar和classes被运行。首先pre-jar调用ensure-release目标以校验是否已经对发布标识符已经设置。结果是形成一个Build系统，这一系统能够使用classes目标（开发人员每一天编译和测试）运行。
使用打包或非打包形式，缺省的Build标识符等，这些轮换构建方法都成为可能。现实中的Build过程通常会比较复杂，但是，只要能够避免javac任务的复本出现，绝大部分的构建都会变得直接明了。
