1.4被误解的Maven
C++之父Bjarne Stroustrup说过一句话：“只有两类计算机语言，一类语言天天被人骂，还有一类没人用。”当然这话也不全对，大红大紫的Ruby不仅有人用，而且骂的人也少。用户最多的Java得到的骂声就不绝于耳了。Maven的用户也不少，它的邮件列表目前在Apache项目中排名第4（http://www.nabble.com/Apachef
90.html）。
让我们看看Maven受到了哪些质疑，笔者将对这些质疑逐一解释。
“Maven对于IDE（如Eclipse和IDEA）的支持较差，bug多，而且不稳定。”
相对于JUnit和Ant来说，Maven比较年轻，IDE集成等衍生产品还不够全面和成熟。但是，我们一定要知道，使用Maven最高效的方式永远是命令行，IDE在自动化构建方面有天生的缺陷。此外，Eclipse的Maven插件——m2eclipse是一个比较优秀和成熟的工具，NetBeans也在积极地为更好地集成Maven而努力，自IntelliJ IDEA开源后，也有望看到其对Maven更好的集成。
“Maven采用了一个糟糕的插件系统来执行构建，新的、破损的插件会让你的构建莫名其妙地失败。”
自Maven 2.0.9开始，所有核心的插件都设定了稳定版本，这意味着日常使用Maven时几乎不会受到不稳定插件的影响。此外，Maven社区也提倡为你使用的任何插件设定稳定的版本。如果我们有好的实践不采纳，遇到了问题就抱怨，未免不够公允。从Maven 3开始，如果你使用插件时未设定版本，会看到警告信息。
“Maven过于复杂，它就是构建系统的EJB 2。”
不要指望Maven十分简单，这几乎是不可能的。Maven是用来管理项目的，清理、编译、测试、打包、发布，以及一些自定义的过程本身就是一件复杂的事情。目前在Java社区还有比Maven更强大、更简单的构建工具吗？答案是否定的。我们可以尝试去帮助Maven让它变得更简单，而不是抛弃它，然后自己实现一套更加复杂的构建系统。
“Maven的仓库十分混乱，当无法从仓库中得到需要的类库时，我需要手工下载复制到本地仓库中。”
Maven的中央仓库确实不完美，你也许会发现某个jar包出现在两个不同的路径下。这不是Maven的错，这是开源项目本身改变了自身的坐标。如果没有中央仓库，你将不得不去开源项目首页寻找下载链接，这不是更费事吗？现在有很多的Maven仓库搜索服务。无法从中央仓库找到你需要的类库？由于许可证等因素，这是完全有可能的，这时你需要做的是建立一个组织内部的仓库服务器，你会发现这会给你带来许多意想不到的好处。
“缺乏文档是理解和使用Maven的一个主要障碍!”
这是事实。Maven官方站点的文档十分凌乱，各种插件的文档更是需要费力寻找。Sonatype编写的《Maven权威指南》很好地改善了这一状况，但由于该书的某些部分与国内的现状有些脱离，且翻译速度无法跟上原版的更新速度，于是笔者编写本书，目的也是帮助大家理解和使用Maven。