附录 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的相关知识。