为什么Eclipse替代不了Maven（自己有些疑惑为什么有了eclipse，干嘛还要用ant，maven等。这篇文章解释的很清楚，也可以理解为替代不了ant）

转自：http://www.juvenxu.com/2010/06/02/why-eclipse-cannt-replace-maven/

声明：此篇文章为转载。

总有那么一批人认为IDE是无比强大的，比如Eclipse，或者更强大的MyEclipse（你是不是在用破解版本？）。Eclipse的确非常、非常、非常的优秀，它能帮你自动编译、帮你执行单元测试、帮你重构……我不想黑Eclipse，要黑的话拿Maven作为对比也太愚蠢了，应该用IDEA才对。我想说的是，Eclipse再强大也替代不了Maven这样的自动化构建工具，为什么昵？

几年前当我还没有毕业的时候，我在一家很小的软件公司实习，这家公司做一些政府项目，当时我们开发的是一个暂住人口管理系统。如果你懂中国，你应该明白这样的公司，技术人员永远是三流公民，单子都是老板通过关系喝酒吃饭拉来的，你开发出来的东西过得去就行，那群办公室里的大爷才不需要你的产品为他们提供多好的体验，他们不在乎这一类体验。因此，不要指望这样的公司对技术有多大的追求。

当时初出茅庐的我还在研究什么是Servlet，什么是JSP，什么是Tomcat，Eclipse也用得半生不熟的，哪还会去关心什么自动化构建，事实上我压根不知道世界上有自动化构建。我一遍又一遍的打包，部署到Tomcat，测试，然后修改，再打包……一个毕业不久的同事看我忙得不亦乐乎，就把MyEclipse的安装包扔给我了（当然，是破解版），然后教我怎么热部署，随改随看，我对他真是感激地要死。

我知道，很多人就是这样爱上MyEclipse的。

可是，IDE终究是只是IDE，有些事情它做不好，就像你用一字螺丝刀去拧十字的螺丝，也许能凑活，但不可能顺手。

用Eclipse你无法做到十分钟构建，更别说持续集成了。什么？你不知道什么是”10 minutes build”，不知道什么是”Continuous Integration”，那么先买几本书扫扫盲吧，例如《解析极限编程》、《敏捷开发的艺术》、《持续集成》。也许你会说“我知道那套敏捷的东西，可是我们公司在做CMMI评审呢，敏捷不适合我，十分钟构建和持续集成也不适合我”，好吧，也许你认为无穷装逼的文档适合你，那就别读下去了，抱歉浪费了你几分钟时间。

在开发软件的时候我们心里要清楚，GUI的操作是很难、或者说不可能自动化的。所以你不可能让电脑帮你点Eclipse中的“签出源码”、“清理项目”、（自动编译就不用点了）、“Run As Test”、……等等按钮。如果你希望将这些操作自动化，那么就需要找一个命令行工具，例如Maven。

不要告诉我你用了m2eclipse一键Build整个项目。

如果你对自动化没有什么追求，你认为点几下鼠标（偶尔点错）不是什么大问题，那允许我再问你一个问题，你能保证你机器的Eclipse配置和你同事的Eclipse配置完全一样么？你保证不了吧？各自配各自的Build Class Path，各自装了各种插件的各种版本，也许你用了正版的MyEclipse，可你同事用了破解版的（其实这种区别不会影响构建，呵呵）。各种微妙差异导致的后果是什么？

你本机编译、测试、打包、部署都没问题，可到了你同事的机器上可能就死活不行，你们坐在一起研究了一下午，最后发现Build Class Path中一个依赖的版本不一致导致了这个问题。

或许你还会说，“我只要协调大家使用一致的Eclipse配置环境就可以避免这个问题”，好吧，假设你能做到。接下来的问题是，如果你的项目有几十个或者上百个第三方依赖，它们还一直会变化，你怎么处理？

“简单！把所有不管有用没用的jar文件都扔进去，然后再慢慢挑掉一点明显不需要的，测一下就行”

是挺简单的，我也这么做过，不过问题很严重。你不能以黑盒的方式来管理项目的依赖。也许你不在乎最终的部署包无谓地增大了几十兆，不在乎这些多余的文件导致打包速度变慢。但是当依赖产生冲突的时候，你就不得不在乎了。一堆jar文件，大的、小的、带版本号的、不带版本号的……祝君好运。

所以你要一个依赖管理工具，例如Maven，或者Ant + Ivy，反正比Eclipse好。

也许你又会说，“我的项目也就10多个依赖，复制几个jar挺简单的，搞Maven那么复杂做什么？”，那么我只能祝愿你永远只需要开发只有10多个依赖的项目，而又能保持工资每年增长25%。

如果你想避免重复劳动、尽早控制风险、更可靠地管理项目依赖，那么就别把什么事情都扔给Eclipse去做。