maven笔记

一、【生命周期】和【阶段】的概念

1.基础概念

• Maven 构建生命周期就是 Maven 将一个整体任务划分为一个个的阶段，类似于流程图，按顺序依次执行。也可以指定该任务执行到中间的某个阶段结束
• Maven 是基于插件的项目，这与其基于阶段的构建过程是分不开的。
• Maven 的每一个构建阶段，都有对应绑定的插件。

注意：

构建阶段和插件是相互独立的。

构建阶段的默认执行插件及目标是通过 packaging 的类型指定的。

所有的生命周期的阶段都是以插件的形式存在的，或者这么说吧，Maven的一切就是一个大插件包集合。

packaging 的类型中定义了一系列的阶段，及每个阶段要执行哪个插件的哪个目标。

Maven 把构建项目的过程，总体分为三个生命周期（lifecycle）：

1.     默认构建：default
2.     项目清理：clean
3.     项目建站：site

这三个生命周期是内置的：默认（default），清洁（clean）和站点（site）。在默认（default）的生命周期处理你的项目部署，将清洁（clean）的生命周期处理项目的清理，而网站（site）的生命周期处理你的项目站点文档的创建。

而每个生命周期又由许多阶段（phase）组成。

而每个阶段，都可以指定默认执行的目标（goal），去具体执行某项工作。

2.阶段与插件的关系

Maven 将构建过程定义为 default lifecycle，并将 default lifecycle 划分为一个个的阶段 phase，这一系列 phase 仅仅是规定执行顺序，至于每个阶段做什么工作？由谁来做？答案就在 插件（plugins） 中。

Maven 对工程的所有操作实实在在的都是由 插件 来完成的。一个插件可以支持多种功能，称之为目标（goal），例如：compiler 插件有两个目标：compile 和 testCompile，分别实现编译源代码 和 编译测试代码。

如何将插件与 Maven 的构建生命周期绑定在一起呢？通过将插件的目标（goal）与 build lifecycle 中 phase 绑定到一起，这样，当要执行某个 phase 时，就调用插件来完成绑定的目标。

如下图所示：从图中可以看出，每一个阶段可以绑定0 个 或 多个目标，每个插件可以提供 1 个或多个目标。

二、默认构建（default）

1.默认（default）的生命周期包括以下阶段：

（注意：这里是简化的阶段，用于生命周期阶段的完整列表，请参阅下方生命周期参考）：

验证（validate） - 验证项目是否正确，所有必要的信息可用
编译（compile） - 编译项目的源代码
测试（test）   - 使用合适的单元测试框架测试编译的源代码。这些测试不应该要求代码被打包或部署
打包（package） - 采用编译的代码，并以其可分配格式（如JAR）进行打包。
验证（verify） - 对集成测试的结果执行任何检查，以确保满足质量标准
安装（install） - 将软件包安装到本地存储库中，用作本地其他项目的依赖项
部署（deploy） - 在构建环境中完成，将最终的包复制到远程存储库以与其他开发人员和项目共享。

这些阶段（以及此处未显示的其他生命周期阶段）是有顺序的，构建时按序逐一执行。

给定上述生命周期阶段，这意味着当使用默认生命周期时，Maven将首先验证项目，然后尝试编译源代码，运行这些源代码，打包二进制文件（例如jar），运行集成测试软件包，验证集成测试，将验证的软件包安装到本地存储库，然后将安装的软件包部署到远程存储库。

换句话说，在生命周期里面阶段是连续的，在不出错的前提下，比如执行打包（package）时就一定是执行了测试（test）之后再执行。

在命令行中使用阶段来执行构建。只需输入阶段名称即可。

Maven会按顺序执行该阶段之前的所有阶段。

例如：

mvn install

mvn clean package （先clean后package）

记住，运行任何一个阶段的时候，它前面的所有阶段都会被运行，这也就是为什么我们运行mvn install的时候，代码会被编译，测试，打包。

2.阶段被绑定了默认的执行插件及目标：

当指定了 packaging 的类型时，

我们可以直接调用阶段的名称来执行 Maven 构建。

因为阶段被默认绑定了一个（或多个） Maven 的核心插件。

然而，我们也可以用命令行调用某个插件的某个目标：

Shell代码  

mvn clean dependency:copy-dependencies package 

以上命令会执行 clean ，然后执行 dependency 插件的 copy-dependencies 目标（goal），

最后执行 package 阶段。

当然，使用内置 packaging 类型时，构建的阶段都是绑定了一个或多个插件，

这些插件被称为【核心插件】。

核心插件的命名规则为：maven-name-plugin

而自定义插件的命名规则为：name-maven-plugin

如果你对 maven 提供的核心插件默认执行的 goal 不满意，

Maven 还允许对核心插件进行配置（通过 plugins标签）。

Maven 的核心插件分为两种：

类型一（Type：B）：Build plugins

类型二（Type：R）：Reporting plugins

三、完整的生命周期（参考）

参考maven官网对生命周期的解释：

https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

提示：在生命周期的阶段上，只有特定的几个阶段对于构建有意义。一些无用的阶段只起到了中间阶段的作用，换句话说只是一个过客。

四、构建项目：给阶段绑定目标

上面说了，可以单独调用某个阶段名称绑定某个插件的某个goal，进行单个步骤的构建。

但是，Maven 的阶段是独立于 goal 的，生命周期中的阶段都没有绑定任何插件的任何 goal。

如果要想一系列的调用阶段，并在每个阶段都绑定一些特定的 goal，该怎么做？

1.整体构建：使用内置的基本打包类型 packaging

Maven 提供了通过指定 packaging 的类型来指定生命周期中的某些阶段所执行特定插件的 goal。

内置的 packaging 的类型包括：jar，war，ear，pom

拿 jar 举例（jar 是 maven 默认的 packaging 类型，packaging 未指定时就是 jar 类型），

如果 packaging 类型是 jar，则其相应的 maven 各个阶段所对应的插件的默认执行的目标如下：

阶段名称                     该阶段所对应的插件及默认调用的目标 
process-resources           resources:resources  
compile                     compiler:compile  
process-test-resources      resources:testResources  
test-compile                compiler:testCompile  
test                        surefire:test  
package                     jar:jar  
install                     install:install  
deploy                      deploy:deploy  

这基本上就是标准的绑定了。但是，不同的 packaging 的类型所调用的阶段和插件也不一样。

例如 packaging 是 pom 的（表明该 project 是一个父类），

只绑定了 install 和 deploy 两个阶段。

另外，如果使用自定义的 packaging 类型，需要在 build 标签的 plugin 标签里加上

extension 值为 true

查看所有内置 packaging 类型在不同的构建阶段（phase）的默认绑定目标（goal）：

http://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html

2、配置 plugin 标签：将插件的 goal 绑定到项目构建的不同阶段中

第二种方法是在 plugins 标签中对每个插件进行配置。

前面已提到，Maven 是基于插件的，并且提供了可以对其核心插件进行配置的功能。

需要注意的是，只是在 build 中引用 plugin 的坐标是不够的，

还需要在 plugin 标签中的 execution 标签中配置在哪个阶段（phase）运行哪些目标（goal）。

新配置的 goal 会添加到阶段中，与阶段中原有的 goal 合并。

执行顺序是先执行原有的，再执行新配置的。

如果配置了多个 execution，它们的 goal 被绑定在相同的阶段，

goal 都会被按配置的顺序逐一执行。当然，还是阶段原有的goal先执行。

阶段原有的 goal 是在 packaging 中定义的。

举例： 

拿 compiler 核心插件举例。该插件有两个目标：compile，testCompile 

前者编译 main 目录下的源码 

后者编译 test 目录下的源码 

packaging 为 jar 时，它在 compile 阶段只绑定了 compiler 插件的 compile 目标。 

即：compile 阶段不执行 testCompile 目标。 

我们可以在 compile 阶段，把 testCompile 目标也添加进来： 

说明： 

这样做只是为了演示用途， 

因为 testCompile 目标被 packaging 为 jar 时，绑定在了 test-compile 阶段上。 

Xml代码 

<build>  
  <finalName>test</finalName>  
  <plugins>  
      <plugin>  
          <groupId>org.apache.maven.plugins</groupId>  
          <artifactId>maven-compiler-plugin</artifactId>  
          <version>3.6.1</version>  
          <executions>  
              <execution>  
                  <configuration>  
                      <target>1.7</target>  
                      <source>1.7</source>  
                  </configuration>  
                  <phase>compile</phase>  
                  <goals>  
                      <goal>testCompile</goal>   
                  </goals>  
              </execution>  
          </executions>  
      </plugin>  
  </plugins>  
</build>  

运行：mvn clean compile 

日志： Java代码 

[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @ test --- 
[INFO] Changes detected - recompiling the module! 
[INFO] Compiling 6 source files to /Users/Eddy/Documents/workspace/Test002-JavaEE/target/classes 
[INFO]  
[INFO] --- maven-compiler-plugin:3.6.1:testCompile (default) @ test --- 
[INFO] Changes detected - recompiling the module! 
[INFO] Compiling 1 source file to /Users/Eddy/Documents/workspace/Test002-JavaEE/target/test-classes 

从执行日志中可以看出，Maven 先执行了 compile 阶段原有的目标：compile， 

而后执行了在 plugins 中新配置的且绑定在 compile 阶段的目标：testCompile 

注意： 

如果在 plugins 中配置的绑定在 compile 阶段的目标也为 compile 的话， 

compile 目标会执行两边！ 

二、Maven构建项目之 build 标签

http://lixh1986.iteye.com/blog/2382352

三、dependencies 标签

    Maven 是可以自动解决依赖包的下载的。

    此处的 dependencies 标签主要用于指定使用某个特定版本的依赖。

    比如指定使用最新版本的依赖包。

四、inherited 标签

    Maven项目中的插件，默认是传递给子项目中起作用的。

    可以使用 inherited 标签，将传递功能禁用。

Maven之setting.xml 配置详解

https://www.cnblogs.com/yangxia-test/p/4409736.html

Maven plugin中的lifecycle、phase、goal、mojo概念及作用的理解

首先，说些题外话，maven的plugin真的很容易写，很多时候，我们只是被plugin这个词吓倒了，总以为插件这玩意，是专家才能写的，我maven都没精通，怎么写得出自己的plugin呢，其实不然，起码在maven中，写一个自己的plugin还是非常简单的，其它软件的插件，要看情况，有些的确是要天才级人物才写得出，有一些呢，也无非是用别人做的傻瓜程序，可以轻松做出来，但是，有决心做，绝大数事情我们是做得到的！

要写自己的maven plugin的话，lifecycle与phase与goal与mojo的概念是一定要理解的，下面是我自己的一些见解

lifecycle：生命周期，这是maven最高级别的的控制单元，它是一系列的phase组成，也就是说，一个生命周期，就是一个大任务的总称，不管它里面分成多少个子任务，反正就是运行一个lifecycle，就是交待了一个任务，运行完后，就得到了一个结果，中间的过程，是phase完成的，自己可以定义自己的lifecycle，包含自己想要的phase

常见的lifecycle有 | clean | package ear | pageage jar | package war | site等等

phase：可以理解为任务单元，lifecycle是总任务，phase就是总任务分出来的一个个子任务，但是这些子任务是被规格化的，它可以同时被多个lifecycle所包含，一个lifecycle可以包含任意个phase，phase的执行是按顺序的，一个phase可以绑定很多个goal，至少为一个，没有goal的phase是没有意义的

下面就是一些default lifecycle的phase

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

基本上，根据名称我们就能猜出每个阶段的用途，关于其它阶段的解释，请参考 http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

记住，运行任何一个阶段的时候，它前面的所有阶段都会被运行，这也就是为什么我们运行mvn install的时候，代码会被编译，测试，打包。

goal: 这是执行任务的最小单元，它可以绑定到任意个phase中，一个phase有一个或多个goal，goal也是按顺序执行的，一个phase被执行时，绑定到phase里的goal会按绑定的时间被顺序执行，不管phase己经绑定了多少个goal，你自己定义的goal都可以继续绑到phase中

mojo: lifecycle与phase与goal都是概念上的东西，mojo才是做具体事情的，可以简单理解mojo为goal的实现类，它继承于AbstractMojo，有一个execute方法，goal等的定义都是通过在mojo里定义一些注释的anotation来实现的，maven会在打包时，自动根据这些anotation生成一些xml文件，放在plugin的jar包里

抛开mojo不讲，lifecycle与phase与goal就是级别的大小问题，引用必须是从高级引用下级（goal绑定到phase，也可理间为phase引用goal，只是在具体绑定时，不会phase定义引用哪些goal，但是执行是，却是phase调用绑定到它那的goal），也不能跨级引用，如lifecycle可以引用任意的phase，不同lifecycle可以同时引用相同的phase，lifecycle不能跨级引用goal。goal会绑定到任意的phase中，也就是说不同的phase可以同时引用相同的goal，所以goal可以在一个lifecycle里被重复执行哦，goal自然也不能说绑定到lifecycle中，它们三者的关系可以用公司里的 总领导，组领导，与职员的关系来解释

Maven_Build_Resources

功能：主要用于打包资源文件，默认情况下maven只打包src/main/resource下的资源，通过：

1、设置build_resources

2、使用build-helper-maven-plugin插件

3、使用maven-resources-plugin插件

都可以自定义要打包的资源

一般情况下，我们用到的资源文件（各种xml，properties，xsd文件）都放在src/main/resources下面，利用maven打包时，maven能把这些资源文件打包到相应的jar或者war里。

有时候，比如mybatis的mapper.xml文件，我们习惯把它和Mapper.java放在一起，都在src/main/java下面，这样利用maven打包时，就需要修改pom.xml文件，来吧mapper.xml文件一起打包进jar或者war里了，否则，这些文件不会被打包的。（maven认为src/main/java只是java的源代码路径）。

maven项目的基本结构

根目录：工程名
|---src：源码
|---|---main:存放主程序
|---|---|---java：java源码文件
|---|---|---resource：存放框架的配置文件
|---|---test：存放测试程序
|---|---|---java：java测试源码文件
|---pop.xml：maven的核心配置文件