这是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直接)进行迁移都是很困难的,甚至是不可能的.