为什么要用Ant?

这是Ant的作者James Duncan Davidson的解释:"我尝试了许多方法来编写一个make文件,从而对于需要重编译的工程,使得其中的所有源文件一次即传递给javac.但是,无论我怎样努力,无论我采用了多少种Make向导工具,仍然无法得到一种能够在多个平台上采用同一方式工作的方法.make文件中的!&#$%#制表符格式实在令我太厌烦了.即便我是Emacs的忠实支持者,我仍然无法忍受一个工具需要用Emacs来编写其文件,以确保不会出现非有意放置的空格.

那是在欧洲参加完一个会议的返航途中,我终于彻底厌倦了,对于创建在任何环境下都能采用同样方式工作的make文件,我已经不打算再去尝试了.我决心"建立"一个自己的工具:这个工具应当能够检查一个工程中的所有Java源文件,将它们与所有已编译的类相比较,并把需要编译的源文件清单直接传给javac.另外,它还应完成其他的一些工作,例如将所有的类填入一个JAR文件中,并复制另外一些文件从而建立该软件的一个可发行版本.为了确保在每个得到支持的平台上都能采用相同方式工作,我决定用Java来编写这个工具."

我的理解

对于许多基于Java的工程而言,对所有Java源文件进行编译已不再是构建这些工程所需的唯一步骤.对于典型的HelloWorld程序、书中的例子以及简单applet,源文件的编译就已经足够了.但是还有一些复杂的基于Java的工程,如Web应用或基于Swing的程序(如JBuilder),要求做更多的工作.必须根据资源控制得到最新的资源;未由Java编译器自动处理的依赖关系也需要得到管理;各种类必须被捆绑并交付到多个位置,有时是作为JAR或WAR文件进行交付;某些Java技术,诸如EJB和RMI类,则需要单独的编译和代码生成步骤,这些均并非由Java编译器完成.shell脚本和GNU make通常是完成这些任务的首选工具,从"完成工作"的角度来说,这些工具可以很好的达到目的,但从长远来看,它们却是不太好的选择.

虽然GNU Make可以提供许多功能,但在易用性方面,却存在许多缺陷.makefile有其自己的语言语法,这就要求编写makefile的人具备此项专门的知识.GNU Make还缺乏平台无关性,因此对于同一个makefile,需要维护和分发多个版本.由于shell脚本和GNU Make(要记住,GNU Make只是现有shell基础上的一个语言扩展)所固有的性质,使得对于任何一个非专家级用户来说,在操作系统直接(甚至shell直接)进行迁移都是很困难的,甚至是不可能的.

    而且GNU Make只能从命令行调用可执行程序.例如,为了调用一个Java类,GNU Make必须使用java命令来调用JVM,再将类名作为命令行参数进行传递.Make不能在程序中使用Java工具的任何库,如异常和错误对象等,而这些库则允许更为灵活的构建过程.对于用Java编写的工具(如WebLogic的ejbc编译器),它们可以与同一JVM中可用的其他对象(如Ant任务对象)共享来自于异常和错误的信息.较之于命令行返回代码和事后的错误消息字符串解析而言,这样做可以改进构建过程.

    而Ant解决了上述问题.Ant在Java编译器作为一个类运行,而不是来自命令行的一个调用.保持在JVM中则允许用特定的代码处理错误,还可以对Sun公司通过其编译器提供的结果采取操作.