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

以前一直用Ant，最近准备上Sonar这个开源的代码质量管理平台，跟MAVEN关系很大，
准备看看，第一印象是：
哇！
好复杂！同时用过两种工具的同仁们，希望不吝赐教，讨论一下：1、MAVEN是真复杂，还是只是看起来复杂？
2、MAVEN比ANT好在哪里？谢谢！

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

主要是可以管理依赖，但是我也很讨厌MAVEN！太难用了！！
附录 A. 需要搞清楚几个问题
A.1. Maven2的优点   1.      对第三方依赖库进行统一的版本管理。      只要用了Maven2就不用再为每个项目复制spring.jar和hibernate.jar了，Maven2会在你需要的时候，自动把这些第三方依赖库找到，你需要编译，Maven2就把这些jar包放到classpath里，你需要打包，Maven2就帮你把需要的jar包都复制到WEB- INF/lib/目录下。
   2.      统一项目的目录结构。      可以保证所有项目的目录结构都是一样的，目录结构统一的好处就是，你要找源代码就去src/main/java/下，你要找需要放到classpath下的资源，就去src/main/resources/下，你要找单元测试对应的代码和资源，就去src/test/下。每个目录下放什么东西，程序编译，发布的时候，每个目录起什么作用都很清楚明了，不会出现打开项目找不到要找的文件的情况。
   3.      统一软件构建阶段      Maven2把软件开发的过程划分成了几个经典阶段，比如你先要生成一些java代码，再把这些代码复制到特定位置，然后编译代码，复制需要放到classpath下的资源，再进行单元测试，单元测试都通过了才能进行打包，发布。      以前使用Ant，最令人头疼的就是要为不同的项目写很多build.xml脚本，而且这些脚本还不太通用，现在我们可以使用Maven2提供的这些经典构建阶段，让每个项目就经过相同的步骤，从源代码一步一步变成可以部署的成品。如果想要什么附加功能，把对应的插件绑定到一个构建阶段上，那么到了执行这个构建阶段的时候，就会执行绑定的插件了。
   4.      支持多种插件      在http://maven.apache.com/和http://mojo.codehaus.org/上可以找到大量的Maven2插件，通过这些插件可以完成多种多样的扩展功能。      不过，如果比插件的易用性，Ant的插件实际上更简单方便，与之相比，在Maven2中配置插件的步骤太复杂了，既要配置groupId和artifactId，还要配置绑定在哪个阶段运行。      不过因为Maven2可以把插件连同第三方依赖一起进行统一版本管理，所以这方面也算比Ant有一点儿优势，至少使用时不需要自己再去下载插件的发布包了。
   5.      自动生成项目网站和报表      如果说Ant可以使用ivy实现第三方依赖库的统一管理，如果说Ant可以自己统一项目的目录结果，如果说Ant支持插件更灵活，那么这个特性绝对是Ant无法比拟的。      Maven2 可以自动为项目生成一个网站，里面包含了项目信息，参与人，项目管理相关的资源，第三方依赖库，使用的插件，以及通过其他扩展插件生成的各种报表。Ant 使用某些插件也可以生成html格式的报表，但是各个报表之间都没什么关联，不像Maven2中将网站和报表都关联在一起，查看起来十分方便。A.2. Maven2的问题   1.      Maven2使用前需要像Ant一样需要配置环境变量。      本来绿色安装是一件好事，但是因为太多人都只会用IDE，不了解如何配置环境变量，所以这第一步就很成问题。
   2.      Maven- 2.1.0本身只有2.844M，可是这只是一个核心，实际使用时，还需要去公网上的资源库下载各种插件，然后才能实现各种功能，问题是公网上的资源库一般都是在国外，网路速度稍慢就无法完成下载，没法下载就没法使用Maven2里提供的那些功能，Maven2就用不起来。      尤其对于新手来说，第一次下载插件的过程，实在是太痛苦了，大多数人都在这一阶段放弃了对Maven2的尝试。
   3.      第三方依赖库版本混乱。      java的依赖库管理一直没有约定规范，导致多个项目，引用多个第三方依赖，这些第三方依赖又使用同一个项目的不同版本的发布包，最后就是弄得一团糟。      Maven2 尝试通过一些约定解决这个版本混乱的问题，但实际上并没有达到预想中的效果。例如，commons.apache.org中的项目，本来应该放在 org/apache/commons/目录下，现在却都各自放在commons-logging，commons-lang，commons- beanutils目录下，估计这是因为刚开始使用Maven2的那些人，懒得把常用包放到那么深的目录结构中，偷懒放到了顶级目录下。可随着 Maven2的发展，加入资源库的包越来越多，他们又把新发布的依赖包按照正常的方式，放到了org/apache/commons/目录下，而旧依赖还有很多人在用，所以也不能删除，这就造成了现在这种一种依赖库多种存放形式的问题。      每次在资源库上找依赖都要花费很多时间，因为你不清楚它究竟使用的哪种目录形式，比如sourceforge.net上的项目就有两种目录形式，一些项目放在net/sf /目录下，而另一些例子放在net/sourceforge/目录下，所以你就算知道项目的网站地址，也要在多个目录下都找一遍。
   4.      缺乏详细的教程      入门教程一般都很简略，现在似乎使用的人多了起来，可以在网上找到一些新手教程，但是一般都很简略，只能自己玩玩，实际中遇到问题的话，还是很难解决。      实际上Maven2的教程一直是一块短板，就算是国外的两本书《Maven: The Definitive Guide 》和《Better Build With Maven》也没有涉及到富含价值高级技术。      就算是讲的比较详细的Maven2教程，也都是停留在Maven2本身的使用上，或者稍微提及一下使用到得官方插件，对于很多强力的扩展插件都没有介绍。      至今很多人用Maven2都处在摸索阶段，没看到谁总结出使用Maven2最佳实践。这点上，一般都是把国外开源项目中的pom.xml拿来研究学习。
   5.      资源库不完整      一般来说，我们可以从Maven2的资源库上下载到我们所需要的第三方依赖库，但是有些依赖库在Maven2的资源库上是找不到的。      其中有因为发布协议的限制，比如j2ee的一些规范api。有因为项目所在厂商的原因，比如jbpm。有因为项目社区的问题，比如birt。还有很多情况是因为Maven2官方处理事情太慢，很多小型开源项目，比如dozer，虽然两个月前就已经提出了最新版本的上传申请，但是迟迟没有给予答复。      在这种情况下，我们只能自己在本地资源库中安装需要的依赖了，造成的问题是，如果相关的项目使用了Maven2的项目管理文件，那么可以使用Maven2将项目发布到本地库中，这样一来就可以获得项目自身的依赖设置。如果相关项目没有使用Maven2的项目管理文件，那么需要自己再去为这个项目找到所需要的依赖，并配置到对应的pom文件中，着实非常麻烦。
   6.      Maven2没有IDE支持      没有良好的IDE支持也是个大问题，虽然说有m2eclipse，但是实际上似乎没那么易用。      本身我们没有使用m2eclipse，而是使用maven2 + editplus的组合，不过介于广大开发者还是要用eclipse的，所以稍后我们还是会讨论到m2eclipse的相关知识。
maven2小教程：
http://family168.com/oa/maven2/html/index.html
"6. Maven2没有IDE支持"，这个过期了，现在Eclipse plugins for Maven已经有了很长时间了。还是官方的好像是3.4以上可装吧忘了
最近也在开始用maven2，第一次使用感觉确实比较麻烦，装了Eclipse plugins for Maven情况稍好些。个人觉得maven2比ANT还是有很多改进的（标准化，一致性等等），所谓万事开头难，当理解和熟练了可能就会体现出Maven强大的地方了。
哎呀，开始出现意见分歧了，好现象。我的第一感觉是麻烦，因为这两天比较忙，所以还没有第二感觉。就目前所知，自动下载lib这个特性让我觉得很郁闷，如果我连不上网怎么办？我需要的jar包如果他的repository没有的话，岂不是又需要配置？
我大部分的工作都是用maven来做的，少量是ant，说说自己的感想。maven搭建工程很快，不需要特殊外挂什么的，直接就可以上手工作；而ant起步就比较麻烦，需要写一大堆东西。也就是说，maven预设了一些方便的功能，而ant只能自己写。maven要想修改默认设定比较麻烦，maven1还好点，是用maven.xml来控制，maven2全部集成到plugin里，麻烦；ant全都在build.xml里，创建的时候虽然工作量大，但修改起来就比较方便。maven对于第三方库文件支持比较好，自动下载存储，还能添加到IDE的工作路径里，对于库文件的管理和团队开发帮助都很大。这个有用的功能导致了工程的移植特别方便，不用进行特殊配置，只要运行maven就可以自动配置好工程的开发环境；ant在这方面没发现有什么特长，工程移植到其他电脑上时配置和调试很麻烦。maven外挂丰富，降低工作繁重程度；ant还是基于手写。比如maven和ant都有自动封装打包的功能，不过maven有许多现成的外挂，添加进pom.xml就可以使用，方便，相比之下ant还是手工劳动程度比较大。maven和ant学习起来都有一个过程，不过ant比maven直观些，毕竟XML一看就能明白，而maven的功能都是基于外挂，所以不太好理解，不过一旦理解maven的原理之后也很容易上手。其实maven和ant干的活和能实现的东西都差不多，就看你喜欢用哪个。个人的一点浅见，供LZ参考。
多谢你的回复，对我来讲很有价值。谢谢。问一下：你说的外挂和plugin是等价的吗？
很少看到傲龙回帖了，呵呵我就用过ant，但是无论用什么，我感觉都是一种习惯，只要想用这些工具我们就只能选择去适应，适应好或适应坏。
是的，我原来也一直用Ant，但现在Sonar这个东西必须跟maven整合（至少我看到是这样），
所以要研究一下mave。这个工作我是安排给一个新毕业的学生的，我看她进度有些慢，所以想了解一下，以便出问题的时候能够有个谱。
探讨一二，也就是说以前写的不管用咯，唉，好严格。我还是觉得，如果上层推不动，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提供了良好的支持？这时要么选择放弃，要么选择妥协。结果就是，当俺们需要免费品尝别人提供的大餐时，就需要接受别人已经制定好的标准咯。
没办法  不见得比ant好用  但时代在前进  得跟进呀
前一段时间学习了一下maven，一些初级的东西看着还行，可遇到问题时，找个资料相当费劲，没有什么实用的资料，而且我觉得框架师或是PM才要学习maven呢，对整个个软件生命周期都相当了解，即使让一个工作了一段时间的人研究maven也不容易吧，遇到问题时，很费劲。你安排给一个新毕业的，有点难为别人了吧。
你也可以再找一个中级的开发人员，让他也学习一下，比较看看效果。
听君一席话，胜读一个月的书啊。你这三篇回复，字字珠玑，非常感谢，我估计如果不是CSDN拦着，您还得写下去，可惜了啊，这个破CSDN的限制。
是啊，我好多年以前就被开源绑架了，不过感觉还是蛮好。
公司管理用MAVEN比较适合点，个人做做私活可以用ANT
当然，如果你对MAVEN比较熟悉，有自己的成熟的模板可以套用，无论做什么样的项目都可以考虑用MAVEN。ANT其实也是可以的。
MAVEN不仅仅是ANT的一个升级，它有很多项目管理上的一些帮助。前面有楼层说过不上网依赖包的问题，这个我是这么认为的，依赖包最好是到公用的地方去下载，这样保证这个依赖包的合法性，公司里由于人员的走动等有些jar包可能是没有版本信息，有些JAR包可能都被修改过的，混乱后也不利于后面的人来维护；如果不可以上网，有两种解决方法：1，在第一次编译的时候进行连网下载，并将此包建立成内网的库映象；2，你确保是正确的版本，copy到内网的库映象中去。
呵呵，工作原因，很少有时间来CSDN。MAVEN我们已经用了很多年了，不过一直在用1
同上所述，一个公司里最多有一两个人会配置maven2即可，剩下人只需要从svn上checkout，然后执行对应的goal即可。实际上我还是感觉maven2这类构建工具应该是项目管理，甚至项目架构人员使用的，楼主的“逆向软件团队管理方式”本意虽然不坏，只是类似让没有学习过任何内功心法的人直接去练乾坤大挪移，九死一生啊。实际上，如果公司拥有内部repo，maven2就可以实现插件共享，可以内部编写的plugin直接deploy到repo上，其他人通过maven2就可以直接配置使用了，这点上看，如果要用ant的话就没那么方便了。再者，maven2很容易让内部所有人强制使用相同的目录结构和开发流程，这也是很多开源支持maven2的原因，因为这些phase和顺序都钉死了，我们只要直接去调用就好了。 ant则太灵活了，你可以随便写，随便写的结果就是只有你自己能用。所以又是二则选择，是选择灵活，然后让跟别人互动搞得十分麻烦，还是接受限制，同时可以和其他人无缝整合？保证自我，还是保证群体，这是个问题。
我现在面临的团队有些混乱，人有点多，所以我还是希望能够统一，
所以，看来改成MAVEN是很有必要的。谢谢大家。
感谢，这个复杂度确实应该会被限制在一定范围内。我现在就是向安排一个专门的人来负责，只是我安排的是一个没有经验的学生而已。
从目前的情况来看，还不算太糟糕。他用了三周左右的时间，把Sonar平台建起来了，Maven也基本有了概念。
我相信三个月以后就会很熟练了。
抽时间看了一下MAVEN官方的文档，对它总算是有一些基本的概念了。从我目前了解的情况来看，使用MAVEN确实很规范，
在便利性方面，比起ANT，
有些地方方便多了，主要是因为其规范的目录结构以及规范的流程，
这样就省的最简单的编译任务还要写脚本，而且用默认的目录结构也很好。但对于依赖的管理方面，个人感觉实在有些麻烦，
目前还没有找到一次性把我已经有的lib加入依赖的方法，
还需要一个个手工配置，真的很烦。也许maven认为这些工作是项目管理过程中保证项目质量的一个部分（所有的依赖都是显式声明的，比较精确？），
而且通常配置完毕后，各项目可以继承，倒也可以接受。
继续研究，看还能不能简化工作量。
有个local的repository，你把你local的包按照maven的约束放进去就好了没用过ant
最近的项目都是maven管理，IDE是eclipse+m2eclipse
感觉确实麻烦一点，maven的目录结构跟ecipse有点矛盾，比如eclipse不会把classes目录列在project下面，但是maven会有个target目录产生
而且动不动就要maven build一把，就算设置成offline，也会不停的下一些pom.xml
ant到maven的转变
ant出一个版本：40分钟
maven出一个版本：1天
我用了有几个月了，
个人感受：
1、各有利弊
2、不是互相替换、对等的两个东西
3、maven的确有好处，就是麻烦
4、楼上说的时间问题，一开始maven比较慢，因为下载啊，手工配置啥的比较多，但后来会越来越快
5、maven对使用者要求高
Maven是一个很优秀的组件，在小的项目中，你可能感觉不到什么特殊的地方，但在大项目中不一样，一个大的项目通常要有N个Project，想想一下你的每个lib下有多少个jar，有一部分是重复的吧，项目越大你的冗余就越多，而且你的.class文件不能像Maven这么方便，直接都在target中，你想往别的服务器上的话，只需要时init-jar.bat这样你要的lib就从公共的文件夹中下载到target中，这样你就可以带着target去部署了。同时他来可以兼容很多的插件。
靳哥，我是yg
来到了一个新公司，参与传输网管的项目，
在熟悉项目的时候，发现公司版本控制使用的是ant，
弄出了好多的xml文件，弄的我头昏脑胀，于是怀念起了在dh时用的maven
所以在网上查找了下ant与maven比较的帖子
无意中查到了你发的这个帖子，心里倍感亲戚
看到帖子的讨论，心里对ant的厌烦程度稍减，
不是觉得ant比maven好用，而是觉得接触陌生事物的时候就是这样的，
开始是枯燥了点，等弄明白了也就有所取舍了，不是一味的反对
看到帖子非常收益并觉得曾经和你共事过是我的幸福
祝：事业有成，女儿健康快乐，全家幸福~！
祝你在新公司好。
ant和maven各有各的优点，也不是能够完全代替的，
ant比较灵活，maven比较规范，
ant理念简单，maven体系复杂。
觉得没有什么好不好的，觉得用的方便，给开发带来方便就是好的。
但是maven确实对eclipse的支持不是很好。有点小麻烦，断网就头大了。