随笔 - 3  文章 - 7  trackbacks - 0
<2007年4月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

常用链接

留言簿(2)

随笔档案

文章分类

文章档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

一Ant与Maven的对比
        提到Maven就不得不提到Ant,Apache Ant is a Java-based build tool.这个是Ant的指南的导言中的第一句话,有两个意思,一是指明ant是基于java语言开发的,另一个意思是指明了ant是一个构建工具。而在Maven的主页上的第一句话Maven is a software project management and comprehension tool.指出了Maven是一个软件项目管理工具,(在此段将Maven翻译成软件项目管理工具我是有疑义的,但网上查看资料都是这样翻译的,而且Project Management直译的确有项目管理的意思,晚些时候再讨论此处)。
        单纯的从字面意思上来理解,根本觉得ant与Maven是风马牛不相及的,而大家对于这两个工具为什么会划上等号,我觉得要从本质上来看Ant与Maven所做的工作了。
        Ant既然是构建工具,那ant可以做哪些事呢?编译代码、单元测试、生成文档、打包、制作安装包、混淆代码、部署等等,ant的功能可以说是非常强大的,不过整个构建过程(构建的生命周期)里需要做哪些事情,完全是需要我们自己思考定义的。
        Maven真正所做的工作其实和ant差不多,也是编译代码、单元测试、生成文档等等,那到底这两个工具间有什么异同呢?
        我想真正的差别还是体现在了思想上,在Maven的介绍页中(http://maven.apache.org/what-is-maven.html)提到Maven最初是在构建处理Jakarta Turbine项目的时候,发现这个项目的几个工程的ant构建脚本只有很细微的差别,于是Maven的作者想将构建工程标准化,对构建过程提供了一个指导性的思想,将项目构建生命周期具体化,(http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)由此我想,为什么Maven的名称定义为Maven,可以认为Maven在思想上提供了专家级的意见的原因吧。
项目的构建生命周期被具体化后,首先是减少了对构建脚本的维护,让多个项目构建生命周期进行重用(也没啥重用的,反正用Maven生命周期都一样),让开发人员都使用这一套规范。
        当然,很多人是不吃这一套的,Maven强制开发人员接受自己定义构建标准除了让人感觉不自由、不灵活外,且担心Maven处理构建生命周期时,内部产生未知问题。还有一些小型项目,根本不需要如此完善的构建生命周期,使用Maven提供的构建生命周期,只是带来了不必要的复杂性。
        所以Maven也不是万金油,仍然需要根据项目的实际情况进行选择,对于涉及人员较多的大型项目,且在软件生命周期上与Maven的标准保持一致的情况下,就可以选择使用Maven。而对于灵活性要求较高、或者一次性的项目,使用Ant足矣。
posted @ 2007-04-29 06:57 SoulEngineer 阅读(1294) | 评论 (2)编辑 收藏
      有可能出自兼容性的考虑、或者是灵活性的考虑、又或者是考虑去除某些用户心理上的FUD,或者几者兼有之,反正Maven是支持Ant脚本的执行的。(具体请看Guide to using Ant with Maven, http://maven.apache.org/guides/mini/guide-using-ant.html)
      Maven将Ant作为一种包含的关系存在,我们可以想象的到Maven应该是在某些方面有超越Ant的表现的,比如在功能上,Maven提供的网站生成与包依赖管理管理特色功能是Ant没有原生提供的。
      比如包依赖管理,包依赖管理真的是很强大且实用的功能,想想我们每个工程都有无数的第三方包需要管理,而这些包进行人工管理(想想人工分析包的版本,第三方包与包之间的依赖等等)真的是一件令人痛苦的事情,引入包依赖管理后,包统一自动管理是多么美妙的一件事情?当然这个功能想用在Ant中也不是不行的!(具体可以看看江南白衣的<<做环保主义者,用Maven2 管理Java类库>>(
http://www.blogjava.net/calvin/archive/2006/03/19/36098.html),由于是Ant去调用了Maven,Maven和Ant肯定是并存于工程中了,也许这样会让一些Ant的铁杆Fans会觉得这样在工程中并不干净了,只是需要Maven提供的一个额外功能就引进了整个Maven,如果是这样, Ant+Ivy的组合对包进行依赖管理可以是另一种选择。
      对于网站的生成,个人感觉这个Ant是可以做到的,提供对应的插件就行了!在google中搜索到这个网站AntDoc web site(http://antdoc.free.fr)好像是提供了类似功能,不过可惜的是我这里打开不了这个网站,并不能肯定是否可行。
      这样子比较下来,好像Ant与Maven又回到了原点,至少Maven能得到的,Ant一样能做到。
      总结一下,我们可不可以这样子理解,Maven以一种包含的关系提供对Ant脚本的支持,只是在内部Plug-in提供功能的基础上提供了另一种选择罢了,这样的话我们在Maven中使用Ant并没有脱离Maven所制定的标准,仍然受到了Maven标准的约束。而Ant在调用Maven包管理,或者使用类似功能的时候,只是类似于命令行调用了对应的命令(插件)罢了,而插件真正调用的,还是Maven的内容。
    我觉得至少可以看出Maven与Ant非竞争对手的关系,必竟也都是一家人(都为Apache一级项目),我想还是项目粒度的问题,两人工具都有生存领域,在技术选型的时候,根据项目的特性再选择对应的工具吧。
posted @ 2007-04-28 21:47 SoulEngineer 阅读(2575) | 评论 (3)编辑 收藏
第一次开技术博,欢迎大家光临!
posted @ 2007-04-28 14:45 SoulEngineer 阅读(169) | 评论 (0)编辑 收藏