自从开始使用Java编程以来，一直都在使用Maven管理软件项目。尽管在使用中遇到了各种各样的问题，但却每次都靠Google解决问题，从未系统地学习过Maven。这次读《Maven实战》，让我真正地系统地学习了一次Maven，再遇到相关问题时，终于可以从原理上分析定位问题所在，有的放矢地快速找寻答案了。

一，为什么Java开发者需要maven

如果你曾开发过大型的软件工具，那么一定清楚为了高效构建一个可用的系统，会使用大量第三方开发的组件而不是事事亲力亲为。软件依赖管理的难题也随之而来。随着依赖的增多，版本不一致，版本冲突，依赖臃肿等问题变得非常棘手。不同的编程语言都有各自的方法来尝试解决包管理的问题，而Maven便是java社区依赖管理最为优秀的解决方案之一。

当然，不仅仅是依赖管理，maven能做的事情还有很多。比如Maven提供了一个供全世界使用的免费中央仓库，其中可以找到任何流行的开源软件；maven还提供了一套java程序生命周期管理的规范，只要遵循这些规范，用户在项目切换时就免去了不必要的学习成本。

二，maven的安装和配置

1，下载并解压到想要安装maven的目录下
2， 设置一个软链接方便以后升级
ln -s apache-maven-3.0 apache-maven
3，配置环境变量（将这两个命令加入~/.bashrc）

export M2_HOME=/home/juven/bin/apache-maven  
export PATH=$PATH:$M2_HOME/bin

4，升级时只需要删除软链接并创建新的软链接到新目录即可
5，一些推荐配置
1）通常需要设置MAVEN_OPTS的值为-Xms128m -Xmx512m，因为Java默认的最大可用内存往往不能够满足Maven运行的需要，比如在项目较大时，使用Maven生成项目站点需要占用大量的内存，如果没有该配置，则很容易得到java.lang.OutOfMemeoryError。因此，一开始就配置该变量是推荐的做法。
2）Maven用户可以选择配置$ M2_HOME/conf/settings.xml或者~/.m2/ settings.xml。前者是全局范围的，整台机器上的所有用户都会直接受到该配置的影响，而后者是用户范围的，只有当前用户才会受到该配置的影响。推荐在安装maven后拷贝一份settings.xml到~/.m2/settings.xml中，这样不需要每次升级都重新拷贝配置文件。
3）有的时候为了访问外部资源，需要配置代理，在settings.xml中配置proxy字段即可

三，Pom文件简介

就像Make的Makefile、Ant的build.xml一样，Maven项目的核心是pom.xml。这个配置文件定义了项目的基本信息，用于描述项目如何构建、声明项目依赖等等。

Pom文件的第一行是XML头，指定了该XML文档的版本和编码方式。紧接着是project元素，project是所有pom.xml文件的根元素，它声明了一些POM相关的命名空间及xsd元素，还有pom模型版本。在project元素中，最重要的一组信息是groupId、artifactId和version。这组信息定义了一个项目的基本坐标：groupId定义了项目属于哪个组织或公司，artifactId是项目的名称而version则是当前项目版本。顺便提一句，我们经常能看到pom文件中的version字段是xxx-SNAPSHOT，这代表了当前版本为测试版本。

如果项目中使用了外部依赖，则要在Pom文件中定义dependency。在pom文件中添加dependencies元素，该元素下可以包含多个dependency元素以声明项目的依赖。每个dependency中同样需要定义一系列坐标属性groupId、artifactId和version（还有两个不太常用的坐标属性packaging和classifier）。此外还可以配置scope属性（比如 test 意味着此依赖只在测试代码中有效，主代码中如果引用则会编译错误），type属性（依赖的类型，大部分情况下不必声明，默认为jar），exclusions（用来排除传递性依赖），optional（标记依赖是否可选）。

关于Pom依赖，这里再多补充几点：
1，依赖具有传递性
2，如果多个依赖传递路径中引用了不同版本的某组件，则maven会进行依赖调解。a.路径最近者优先; b.第一声明者优先
3，可选依赖不会被传递。理想情况下，是不应该使用可选依赖的。
4，优化依赖
可以执行以下命令看到当前项目的依赖树
mvn dependency:tree 在此基础上，还有dependency:analyze工具可以帮助分析当前项目的依赖

四，maven生命周期

mvn clean compile test package

这些我们平时编译工程时经常敲的命令其实就是Maven的生命周期。在Maven出现之前，项目构建的生命周期就已经存在，软件开发人员每天都在对项目进行清理、编译、测试及部署。虽然大家都在不停地做构建工作，但公司和公司间、项目和项目间，往往使用不同的方式做类似的工作。Maven的生命周期就是为利对所有的构建过程进行抽象和统一。这个生命周期包含了项目的清理、初始化、编译、测试、打包、集成测试、验证、部署和站点生成等几乎所有构建步骤。Maven的生命周期是抽象的，这意味着生命周期本身不做任何实际的工作，在maven的设计中，实际的任务都交由插件来完成。

初学者往往会以为Maven的生命周期是一个整体，其实不然，Maven拥有三套相互独立的生命周期，它们分别是clean、default和site。每个生命周期包含一些阶段，这些阶段是有序的，并且后面的阶段依赖于前面的阶段。以clean生命周期为例，它包含的阶段有pre-clean、clean、和post-clean。

我们在执行一个mvn命令时，其实不仅仅是执行指定的插件，还会执行其生命周期中该插件之前的所有阶段，比如我们执行mvn clean install：该命令调用clean生命周期的clean阶段和default生命周期的从validate至install的所有阶段。

五，使用ArcheType生成项目骨架

每一个团队都有其习惯的软件架构和风格。当我们第一次创建项目骨架时，我们往往很耐心地创建每一级目录、每一个文件并思考为什么是这样。但当我们第二次、第三次创建工程时，我们会慢慢对这种重复性的劳动感到厌恶。既然每次创建的项目骨架都是大同小异的，为什么不能把重复的工作自动化呢？Maven的Archetype插件就为我们提供了快速生成项目骨架的工具。

mvn archetype:generate

用户输入上述命令后，Archetype插件会输出一个列表供用户选择。用户选择了想要的模板编号后，系统会提示用户输入一些关键参数：如groupId、artifactId、version、package等等。用户在自己编写Archetype时还可以声明额外的配置参数。根据Maven提示填写完配置参数之后，Archetype插件就能够生成项目的骨架了。

书中列举了一些常用的项目骨架，以及如何自定义团队的项目骨架，在此不多赘述，需要的时候可以翻书查找一下。