1 坐标

1 什么是坐标？

在平面几何中坐标（x,y）可以标识平面中唯一的一点。在maven中坐标就是为了定位一个唯一确定的jar包。
Maven世界拥有大量构建，我们需要找一个用来唯一标识一个构建的统一规范
拥有了统一规范，就可以把查找工作交给机器

2 Maven坐标主要组成

maven坐标元素包括groupId，artifactId，version，packaging，classifier。只要提供正确的坐标元素，maven就能找到对应的构件。

基本坐标简解

groupId：（公司或组织域名倒序） 定义当前这个maven项目录属的实际项目，表示方式通常与域名反向相对应。
artifactId：（模块名，也是实际项目的名称 ）定义实际项目中的一个maven项目，推荐做法使用实际项目名称作为artifactId的前缀。 maven生成的构件，其文件名会以artifactId作为开头。
version：定义maven项目当前所处的版本。
packaging：定义maven项目的打包方式，如果不定义packaging，默认使用jar。
classifier：帮助定义构建输出的一些附属构件。不能直接定义classifier。
详解
1 groupId
定义当前Maven项目隶属的实际项目。首先，Maven项目和实际项目不一定是一对一的关系。比如SpringFramework这一实际项目，其对应的Maven项目会有很多，如spring-core、spring-context等。这是由于Maven中模块的概念，因此，一个实际项目往往会被划分成很多模块。其次，groupId不应该对应项目隶属的组织或公司。原因很简单，一个组织下会有很多实际项目，如果groupId只定义到组织级别，而后面我们会看到，artifactId只能定义Maven项目（模块），那么实际项目这个层将难以定义。最后，groupId的表示方式与Java包名的表示方法类似，通常与域名反向一一对应。上例中，groupId为org.sonatype.nexus，org.sonatype表示Sonatype公司建立的一个非营利性组织，nexus表示Nexus这一实际项目，该groupId与域名nexus.sonatype.org对应。

2artifactId
该元素定义实际项目中的一个Maven项目（模块），推荐的做法是使用实际项目名称作为artifactId的前缀。比如上例中的artifactId是nexus-indexer，使用了实际项目名nexus作为前缀，这样做的好处是方便寻找实际构件。在默认情况下，Maven生成的构件，其文件名会以artifactId作为开头，如nexus-indexer-2.0.0.jar，使用实际项目名称作为前缀之后，就能方便从一个lib文件夹中找到某个项目的一组构件。考虑有5个项目，每个项目都有一个core模块，如果没有前缀，我们会看到很多core-1.2.jar这样的文件，加上实际项目名前缀之后，便能很容易区分foo-core-1.2.jar、bar-core-1.2.jar…

3 version
该元素定义Maven项目当前所处的版本，如上例中nexus-indexer的版本是2.0.0。需要注意的是，Maven定义了一套完成的版本规范，以及快照（SNAPSHOT）的概念。

4 packaging
该元素定义Maven项目的打包方式。首先，打包方式通常与所生成构件的文件扩展名对应，如上例中packaging为jar，最终的文件名为nexus-indexer-2.0.0.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的典型例子是TestNG，TestNG的主构件是基于Java1.4平台的，而他又提供了一个classifier为jdk5的附属构件。注意，不能直接定义项目的classifier，因为附属构建不是项目直接默认生成地，而是由附加的插件帮助生成。

上述5个元素中，groupId、artifactId、version是必须定义的，packaging是可选的（默认为jar），而classifier是不能直接定义的。

同时，项目构建的文件名和坐标相对应的，一般的规则为artifactId-version [-classifier] .packaging，[-classifier]表示可选。比如上例nexus-indexer的主构件为nexus-indexer-2.0.0.jar，附属构建有nexus-indexer-2.0.0-javaodc.jar。这里还要强调一点是，packaging 并非一定与构件扩展名对应，比如packaging为maven-plugin的构件扩展名为jar。

<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.0</version>//以上三个为依赖的基本坐标，maven根据坐标才能找到依赖
        <type>jar</type>//依赖的类型
        <scope>test</scope>//依赖的范围
        <classifier>jdk15</classifier>//它表示在相同版本下针对不同的环境或者jdk使用的jar
        <optional>true</optional>//是否为可选依赖
        <exclusions>//用来排除传递性依赖
            <exclusion>
                <groupId>org.apache.maven</groupId>
                <artifactId>maven-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
  </dependencies>

2生命周期

Maven 构建生命周期定义了一个项目构建跟发布的过程。
一个典型的 Maven 构建（build）生命周期是由以下几个阶段的序列组成的：


为了完成 default 生命周期，这些阶段（包括其他未在上面罗列的生命周期阶段）将被按顺序地执行。

Maven 有以下三个标准的生命周期：

clean：项目清理的处理
default(或 build)：项目部署的处理
site：项目站点文档创建的处理

生命周期可以理解为项目构建的步骤集合。

生命周期是由多个阶段（Phase）组成。每个阶段都是一个完整的功能，比如mvn clean中的clean就是一个阶段。

1 Clean生命周期

pre-clean 执行一些需要在clean之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在clean之后立刻完成的工作

mvn clean命令，等同于 mvn pre-clean clean。只要执行后面的命令，那么前面的命令都会执行，不需要再重新去输入命令。

有Clean生命周期，在生命周期又有clean阶段。

2 Default生命周期（重点）

validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件，至目标目录，准备打包。
compile 编译项目的源代码。
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件，至目标测试目录。
test-compile 编译测试源代码。
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码，打包成可发布的格式，如 JAR 。
pre-integration-test
integration-test
post-integration-test
verify
install 将包安装至本地仓库，以让其它项目依赖。
deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享。
在maven中，只要在同一个生命周期，你执行后面的阶段，那么前面的阶段也会被执行，而且不需要额外去输入前面的阶段，这样大大减轻了程序员的工作。

3 Site生命周期

pre-site 执行一些需要在生成站点文档之前完成的工作
site 生成项目的站点文档
post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
site-deploy 将生成的站点文档部署到特定的服务器上

3依赖管理

依赖范围

其中依赖范围scope 用来控制依赖和编译，测试，运行的classpath的关系. 主要的是三种依赖关系如下：

1.compile： 默认编译依赖范围。对于编译，测试，运行三种classpath都有效
2.test：测试依赖范围。只对于测试classpath有效
3.provided：已提供依赖范围。对于编译，测试的classpath都有效，但对于运行无效。因为由容器已经提供，例如servlet-api
4.runtime:运行时提供。例如:jdbc驱动

依赖传递

A、B、C

B工程依赖A工程，C工程依赖B工程，那么B工程是C工程的直接依赖，A工程是C工程的间接依赖

标题依赖范围传递


 当第二依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致。
 当第二直接依赖的范围是test的时候，依赖不会得以传递。
 当第二依赖的范围是provided的时候，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为 provided；
 当第二直接依赖的范围是runtime的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递的依赖范围为runtime；

标题依赖冲突

1 跨pom文件的冲突
MavenFirst的pom文件中依赖来junit的4.9版本，那边MavenSecond和MavenThird中都是使用了4.9版本。

如果MavenSecond中重新依赖junit的4.8版本，那么MavenSecond和MavenThird中都是使用了4.8本，这体现来依赖的就近使用原则。

依赖的jar包如下：

2 同一个pom文件的冲突

可选依赖

排除依赖

4插件

我们都知道Maven本质上是一个插件框架，它的核心并不执行任何具体的构建任务，所有 这些任务都交给插件来完成，例如编译源代码是由maven- compiler-plugin完成的。
插件（plugin），每个插件都能实现一个阶段的功能。Maven的核心是生命周期，但是生命周期相当于主要指定了maven命令执行的流程顺序，而没有真正实现流程的功能，功能是有插件来实现的。

比如：compile就是一个插件实现的功能。
编译插件

Tomcat插件
如果使用maven的tomcat插件的话，那么本地则不需要安装tomcat。