参考书籍Maven实战:可在InfoQ的Minibook出下载相关电子版。
一、坐标
maven坐标为各种构件引入了秩序，任何一个构件都必须明确定义自己的坐标，而一组maven坐标是通过一些元素定义的，它们是groupId,artifactId,version,packaging,chassifier。先看一组坐标定义，如下：
下面详细解释一下各个坐标元素：
1.groupId: 定义当前maven项目隶属的实际项目。首先，maven项目和实际项目不一定是一对一的关系。比如SpringFramework这一实际项目，其对应的maven项目会有很多，如: spring-core，spring-context等。这是由于maven中模块的概念，因此，一个实际项目往往会被划分成很多模块。其次，groupId不应该对应项目隶属的组织或公司。原因很简单，一个组织下会有很多个实际项目，如果groupId只定义到组织级别，而后面我们会看到，artifactId只能定义maven项目(模块),那么实际项目这个层将难以定义。最后，groupId的表示方式与java包名的表示方式类似，通常与域名反向一一对应。
2.artifactId: 该元素定义实际项目中的一个maven项目(模块),推荐的做法是使用实际项目名称作为artifactId前缀，这样做的好处是方便寻找实际构件。在默认情况下，maven生成的构件，其文件名会以artifactId作为开头，如:nexus-indexer-2.0.0.jar，使用实际项目名称作为前缀之后，就能方便从一个lib文件夹中找到某个项目的一组构件。
3.version: 该元素定义maven项目当前所处的版本，如：nexus-indexer-2.0.0.jar的版本是2.0.0。需要注意的是，maven定义了一套完整的版本规范，以及快照(SNAPSHOT)的概念。
4.packaging: 该元素定义maven项目的打包方式。首先，打包方式通常与所生成构件的文件扩展名对应，如：nexus-indexer.2.0.0.jar的packaging为jar，而使用war打包方式的maven项目，最终生成的构件会有一个.war文件，不过这不是绝对的。其次，打包方式会影响到构建的生命周期，比如jar打包和war打包会使用不同的命令。最后，当不定义packaging的时候，maven会使用默认值jar。
5.classifier: 该元素用来帮助定义构建输出的一些附属构件。附属构件与主构件对应，如上例中的主构件是: nexus-indexer-2.0.0.jar，该项目可能还会通过使用一些插件生成如：nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar这样一些附属构件，其包含了java文档和源代码。这时候，javadoc和sources就是这两个附属构件的classifier。这样，附属构件也就拥有了自己唯一的坐标。
注意：不能直接定义项目的classifier，因为附属构件不是项目直接默认生成的，而是由附加的插件帮助生成。
上述5个元素中，groupId，artifactId，version是必须定义的，packaging是可选的(默认为jar)，而classifier是不能直接定义的。
同时，项目构件的文件名是与坐标相对应的，一般的规则为:artifactId-version[-classifier].packaging，[-classifier]表示可选。
二、依赖
- 依赖与依赖的配置
顾名思义，依赖就是当用到其他模块作为为其服务时而产生的一种关系，通过其坐标找到其对应模块。进而引出有关依赖的配置，如下是一个很常见的POM配置
junit junit 4.5 jar test - groupId,artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，maven根据坐标才能找到需要的依赖。
- type:依赖的类型，对于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值为jar。
- scope:依赖的范围。
- optional:标记依赖是否可选。
- exclusions：用来排除传递性依赖。
- 依赖范围
举例来说，你开发时需要做测试，你需要依赖于junit的jar，但是部署应用时并不需要它，因为单元测试不会在生产环境上跑，也就是说最终打包的jar或者war不包含junit的jar。又如你开发web程序，你的servlet/jsp进行编译需要依赖于servlet-jsp的标准api（J2EE的jar），但是部署时也是不需要它的，因为你的应用服务器肯定有这些东西。
因此，Maven考虑了6中可能的scope供选择：
- compile: 默认的scope。编译、测试、打包全都需要。compile参与依赖传递，就是说，你的项目A依赖于B(依赖scope是compile)，项目C依赖于你的项目A，那么C也就依赖于B。
- provided: 表示JDK或者容器会在Runtime时提供这些(jar)，如上面说到的servlet api。provided的东西在编译和测试时会用到，不参与传递依赖。
- runtime: 表示编译时不需要，但测试和运行时需要，最终打包时会包含进去。
- test: 只用于测试阶段（测试的编译和测试的运行），典型的就是junit的jar。
- system: 和provided类似，但要求jar是你的系统里已有的，不会在repository里找，如rt.jar,tools.jar这些。
- import: 简单的说，你的项目的pom可以继承另一个项目的pom，从而继承了父项目的依赖关系，但是因为之后single inheritance的限制，所以创造了import，使得你可以“导入”或者说“继承”任何一到多个项目的依赖关系。
如果你要考虑更细一些，你的项目依赖于A（scope1），A依赖于B（scope2），那么你的项目对B的依赖应该算是哪个scope呢？官方文档上有个表格，列举了scope1和scope2的一个矩阵关系（各自都可能是compile/provided/runtime/test），然后最后结果应该是什么。
- 依赖的传递性
传递性依赖：account-mail有一个compile范围的spring-core依赖，spring-core有一个compile范围的commons-logging依赖，那么commons-logging就会成为account-mail的compile范围依赖。 - 依赖调解
maven引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面大部分情况下我们只需要关心项目直接依赖的是什么，而不用考虑这些依赖会引入什么传递性依赖。但有时候，当传递依赖造成问题的时候，我们需要清楚地知道该传递性依赖是从哪条依赖路径引入的。
maven依赖调解的两个原则。（1）第一原则是：路径最近者优先。（2）第二原则是：第一声明者优先。在依赖路径长度相等的前提下，在pom依赖声明的顺序决定了谁会解析使用，顺序最靠前的那个依赖优胜。 - 可选依赖
假设有这样一个依赖关系，项目A依赖于项目B，项目B依赖于项目X和Y，B对于X和Y的依赖都是可选依赖：A-->B,B-->X(可选),B-->Y(可选)。根据传递性依赖的定义，如果所有这三个依赖的范围都是compile，那么X,Y就是A的compile范围传递性依赖。然而，由于这里X,Y是可选依赖，依赖将不会得以传递。换句话说，X,Y将不会对A有任何影响。
为什么要使用可选依赖这一特性呢？可能项目B实现了两个特性，其中的特性一依赖于X，特性二依赖于Y，而且这两个特性是互斥的，用户不可能同时使用两个特性。比如B是一个持久层隔离工具包，它支持多种数据库，包括MySQL,PostgreSQL等，在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一个数据库。