ant maven 比较

前几天因为可能要用到MAVEN，所以在优快云论坛发表了一篇帖子

各抒己见：MAVEN比ANT好在哪里

来征求大家的意见，现将讨论内容整理如下：

 

xyz20003 连发三篇，阐明了自己的看法：

探讨一二，也就是说以前写的不管用咯，唉，好严格。

我还是觉得，如果上层推不动，maven2这种纯构建的东东就用不起来。你说让一个刚毕业的，连软件开发流程的同志搞maven2，有点儿难哦，

至少他要知道maven2是做什么的，每个phase都是用来做什么的，为什么test要放在package前面，为什么要有integration- test，为什么要区分version进行依赖。为什么目录结构区分main和test，下级目录为什么又要保持java和resource分开，为什么 要统一将生成的文件放到target下。

如果了解了这些，可以用ant写一个功能与maven2相近的脚本出来，虽然build.xml会稍大一些。不过灵活完全可以定制。

不是说ant不好，你看spring都是用ant编译的，你看他们写了多少脚本？

最后，我的感觉呢，是这样的：

你如果自己写个小工具玩玩，ant既灵活，运行又快。
如果这个东西需要与人分享，或者希望达到一种团队内部的标准，那么用maven2吧，它就是标准化的一个范例。你看多少apache项目都在用maven2，学会maven2的好处就是可以很快看懂这些项目的结构，用最快的速度把一个项目构建起来，减少沟通的壁垒。

所以，你如果在企业内部，用不用maven2都看你自己的爱好了，如果你学习开源，那还是赶快学学吧。

ant现在发布包，大概18m
maven2的发布包，大概2.8m

在下本地的repo大概1G，主要因为之前的version太多了。

但是每次你要为ant添加一个功能，都要自己去找lib。
maven下直接配置一个，它就自己去下载了。

又有人说，我的项目都是ssh，我直接copy就行了。

这点我真比不了，google code上放个开源项目，我如果把lib都放上去，每个项目估计都上百m，maven2的话，这些东西至少不用放到svn里去了。

还是那句话，企业内部是个很狭小的圈子，maven2虽然可以保证一部分标准化，但是完全没有开源那么大的利益。所以自己估量着办吧。你要是能把maven2的开发过程搞清楚，自己也可以用ant写一套这样的脚本了。插件自己配，依赖自己找，一样的。

但是为什么我们要学maven2，因为不重复造轮子，别人已经写好了的。

又看了一下LZ的问题，原来是因为sonar。

这就是企业被开源绑架的一个例子，你本来不想学这个东西，但是开源已经在广泛使用了，君不见hudson也对maven2提供了良好的支持？这时要么选择放弃，要么选择妥协。

结果就是，当俺们需要免费品尝别人提供的大餐时，就需要接受别人已经制定好的标准咯。

miaoliujun 重点阐述了对依赖问题的看法：

公司管理用MAVEN比较适合点，个人做做私活可以用ANT
当然，如果你对MAVEN比较熟悉，有自己的成熟的模板可以套用，无论做什么样的项目都可以考虑用MAVEN。ANT其实也是可以的。
MAVEN不仅仅是ANT的一个升级，它有很多项目管理上的一些帮助。

前面有楼层说过不上网依赖包的问题，这个我是这么认为的，依赖包最好是到公用的地方去下载，这样保证这个依赖包的合法性，公司里由于人员的走动等有些 jar包可能是没有版本信息，有些JAR包可能都被修改过的，混乱后也不利于后面的人来维护；如果不可以上网，有两种解决方法：1，在第一次编译的时候进 行连网下载，并将此包建立成内网的库映象；2，你确保是正确的版本，copy到内网的库映象中去。

至于复杂性的问题，我承认要理解一个理念是很复杂，但一个公司只需要一个人去理解，其他人不需要全部理解，知道怎么做即可。

xyz20003 对于miaoliujun 提出来的复杂度问题，又做了阐释：

同上所述，一个公司里最多有一两个人会配置maven2即可，剩下人只需要从svn上checkout，然后执行对应的goal即可。

实际上我还是感觉maven2这类构建工具应该是项目管理，甚至项目架构人员使用的，楼主的“逆向软件团队管理方式”本意虽然不坏，只是类似让没有学习过任何内功心法的人直接去练乾坤大挪移，九死一生啊。

实际上，如果公司拥有内部repo，maven2就可以实现插件共享，可以内部编写的plugin直接deploy到repo上，其他人通过maven2就可以直接配置使用了，这点上看，如果要用ant的话就没那么方便了。

再者，maven2很容易让内部所有人强制使用相同的目录结构和开发流程，这也是很多开源支持maven2的原因，因为这些phase和顺序都钉死了，我们只要直接去调用就好了。 ant则太灵活了，你可以随便写，随便写的结果就是只有你自己能用。

所以又是二则选择，是选择灵活，然后让跟别人互动搞得十分麻烦，还是接受限制，同时可以和其他人无缝整合？

保证自我，还是保证群体，这是个问题。

最后是我经过几天学习以后的粗浅看法：

抽时间看了一下MAVEN官方的文档，对它总算是有一些基本的概念了。

从我目前了解的情况来看，使用MAVEN确实很规范，
在便利性方面，比起ANT，
有些地方方便多了，主要是因为其规范的目录结构以及规范的流程，
这样就省的最简单的编译任务还要写脚本，而且用默认的目录结构也很好。

但对于依赖的管理方面，个人感觉实在有些麻烦，
目前还没有找到一次性把我已经有的lib加入依赖的方法，
还需要一个个手工配置，真的很烦。

也许maven认为这些工作是项目管理过程中保证项目质量的一个部分（所有的依赖都是显式声明的，比较精确？），
而且通常配置完毕后，各项目可以继承，倒也可以接受。

继续研究，看还能不能简化工作量。

从复杂度来讲，MAVEN和ANT真不是一个级别的，带来的问题在某些情况下也相当严重，

我今天就碰到了下载一个插件失败而导致整个工程完全无法编译下去的情况。

像类似的问题，如果不是深入了解MAVEN，恐怕解决起来都相当棘手。

 

ITEYE http://www.iteye.com/topic/21445

转贴www.matrix.org.cn 上的 maven和ant的比较

第一：每次和别人说maven的时候，很多会认为是全新的东西而不肯放弃ant。其实，ant脚本是可以直接运行在maven中的。

如果要说maven和ant有什么差别，我觉得最大的差别就是在于maven的编译以及所有的脚本都有一个基础，就是POM（project object model）。这个模型定义了项目的方方面面，然后各式各样的脚本在这个模型上工作，而ant完全是自己定义，显然maven更胜一筹。

第二：Maven对所依赖的包有明确的定义，如使用那个包，版本是多少，一目了然。而ant则通常是简单的inclde 所有的jar。导致的最终结果就是，你根本无法确定JBoss中的lib下的common－logging 是哪个版本的，唯一的方法就是打开 META－INF 目录下MANIFEST.MF。估计JBoss迟早会转向Maven的。

第三：Maven是基于中央仓库的编译，即把编译所需要的资源放在一个中央仓库里，如jar，tld，pom，等。当编译的时候，maven会自 动在仓库中找到相应的包，如果本地仓库没有，则从设定好的远程仓库中下载到本地。这一切都是自动的，而ant需要自己定义了。这个好处导致的结果就是，用 maven编译的项目在发布的时候只需要发布源码，小得很，而反之，ant的发布则要把所有的包一起发布，显然maven又胜了一筹。

        也说第三条，你遇到的问题大概是从网上下的用 maven 的项目("实际的效果是，你下载了基于maven的项目源码后，基本没法编译。因为很多包下载不了，或者版本不对。越老的项目越有可能无法编译。 ") ，可是作为自己公司的项目，用同一个中央仓库会带来很大的便利，不会到处找各个组件包，会很快找到需要的版本。如果自己管理的话会很麻烦！

第四：maven有大量的重用脚本可以利用，如生成网站，生成javadoc，sourcecode reference，等。而ant都需要自己去写。试试 maven site 的效果。

第五：maven目前不足的地方就是没有象ant那样成熟的GUI界面，不过mavengui正在努力中。目前使用maven最好的方法还是命令行，又快又方便。