最近看youmeek的Intellij教程，学习完Git的使用，接下来就是Maven了。

构建工具的进化史：Ant-Maven-Gradle

网上看到有人这样感叹，错过了Ant时代，也错过了Maven时代，再也不能错过了Gradle时代了，Gradle作为新生代的构建工具，取代Maven的趋势已经很明显，Spring的代码依赖管理已经换用了Gradle。Gradle解决了Maven配置文件过于冗长的问题，同时使用grooy配置并整合了Ant，灵活性等方面较之前的构建工具有不少优势，但是现在的成熟项目中使用Gradle的产品却并不多（通常是安卓项目），Maven仍然占主流。

Maven遵循约定优于配置原则

源代码应该放置到src/main/java中

源代码的资源文件应该放置在src/main/resources文件夹中

测试代码应该放置到src/test/java中

测试代码的资源文件应该放置在src/test/resources文件夹中

项目配置

pom.xml

基本配置

title

版本号说明（version）

格式：

总版本号.分支版本号.小版本号-里程碑版本

总版本号：一般表示框架的变动

分支版本号：一般表示增加了一些功能

小版本号：在分支版本上面进行bug的修复

里程碑：SNAPSHOT–>alpha–>beta–>release–>GA

user0.0.1-SNAPSHOT-->user0.0.1-Release-->user1.0.0SHAPSHOT  -->user1.0.0-Rlease
                                         -->user0.1.0-SNAPSHOT-->user0.1.0-Rlease

定义变量

<properties>
    <spring.version>1.2.6</spring.version>
</properties>

<dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-core</artifactId>
 <version>${spring.version}</version>
</dependency>

依赖

所有的依赖都是通过坐标来进行存储的（GAV–>groupId、artifactId、version）
有一些网上的仓库提供了坐标的查询（http://mvnrepository.com）
通过dependencies设置依赖（maven是如何搜索依赖的？首先会在本地仓库查询如果本地仓库没有，就去中央仓库查询）

依赖传递

A–>C B–>A ==> B–>C（这种依赖是基于compile这个范围进行传递）

title

依赖冲突

A–>B1.0

C–>B1.1

D–>A、C

这个时候在D的pom中，哪一个依赖先写就使用先写依赖的版本

如果D优先配置对A的依赖<dependency>A</dependency><dependency>C</dependency>，依赖版本是B1.0

A–>B1.0

C–>B1.1

D–>A和C–>B1.0

F–>D、C

如果路径的长短不一致就选择最小路径，F–>B1.1

如果希望精确的控制依赖包，可以使用依赖的排除功能进行控制

title

依赖范围

test范围指的是测试范围有效，在编译和打包时都不会使用这个依赖，如：Junit

compile范围指的是编译范围有效，在编译和打包时都会将依赖存储进去，如：Spring

provided范围指的是编译和测试的过程有效，最后生成war包时不会加入，如：Servlet-api（Servlet-api，Tomcat等Web服务器已经存在了，如果再打包会冲突）

runtime范围指的是运行的时候依赖，在编译的时候不依赖，如：Jdbc驱动

默认的依赖范围是Compile

聚合和继承

聚合

父pom.xml文件声明聚合子项目

title

继承

父pom.xml文件

title

子pom.xml文件

title

子pom继承的依赖声明只需包含groupid和artifactid，不需要包含versionid

生命周期和插件

clean

pre-clean 执行一些需要在clean之前完成的工作

clean 移除所有上一次构建生成的文件

post-clean 执行一些需要在clean之后立刻完成的工作

compile

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 将最终的包复制到远程的仓库，以让其它开发人员与项目共享。

site

pre-site 执行一些需要在生成站点文档之前完成的工作

site 生成项目的站点文档

post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备

site-deploy 将生成的站点文档部署到特定的服务器上

Maven常用命令

mvn clean –>表示运行清理操作（会默认把target文件夹中的数据清理）
mvn clean compile–>表示先运行清理之后运行编译，会见代码编译到target文件夹中
mvn clean test–>运行清理和测试
mvn clean package–>运行清理和打包
mvn clean install–>运行清理和安装，会将打好的包安装到本地仓库中，以便其他的项目可以调用
mvn clean deploy–>运行清理和发布（发布到私服上面）

插件

插件是maven的核心，所有执行的操作都是基于插件来完成的

为了让一个插件中可以实现众多的类似功能，maven为插件设定了目标，一个插件中有可能有多个目标

其实生命周期中的重要的每个阶段都是由插件的一个具体目标来执行的

Maven tomcat插件

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.tomcat.maven</groupId>
            <artifactId>tomcat6-maven-plugin</artifactId>
            <version>2.2</version>
            <configuration>
                <path>/</path>
                <port>8080</port>
                <uriEncoding>UTF-8</uriEncoding>
                <!--<url>http://localhost:8080/manager/html</url>-->
                <server>tomcat7</server>
                <mode>context</mode>
                <contextFile>src/main/resource/context.xml</contextFile>
                <!--<ignorePackaging>true</ignorePackaging>-->
                <addContextWarDependencies>true</addContextWarDependencies>
            </configuration>
        </plugin>
    </plugins>
</build>