Maven简介

maven将工程（Project）的构建过程理解为不同的生命周期(LifeCycle)和阶段（Phase）, 在工程的构建过程中，存在着不同的生命周期，这些生命周期互相独立，之间也没有一定的顺序关系。
每个生命周期又划分为不同的阶段（Phase）。阶段之间有明确的顺序关系， 同一生命周期内的阶段必须按顺序依次执行。
maven内置了三个生命周期，并为每个生命周期内置了一些阶段
default：构建（Build）
validate：验证项目是否正确，所有必需的信息是否可用。
compile：编译项目中的代码。
test：用相关的单元测试框架测试编译后的代码，这些运行的测试并不会随项目打包和布署。
package：将编译后的代码打包成相应的格式文件，如jar包。
integration-test： 如果需要在一个综合环境中运行我们的测试，这个阶段将会运行和布署项目到该环境中。
verify： 检查项目的包是否正确和符合要求。
nstall：将包安装到本地maven仓库，可以让其他项目作为依赖使用该包。
eploy：将包发布到远程的maven仓库，并提供给其他开发者使用。
clean：清理
pre-clean 准备清理
clean 执行清理工作
post-clean 执行清理后的后续工作
site：生成项目文档和站点
pre-site 准备生成
site 生成项目站点和文档
post-site 执行生成文档后的后续工作
site-deploy 发布项目文档

在生命周期的各个阶段里面都有有对应的插件,一个插件可以实现多个目标（Goal）

maven核心概念
LifeCycle 生命周期，maven内置default,sie,clean三个生命周期
Phase 阶段，每个生命周期有不同的阶段
Plugin 插件，实现实际的构建功能
Goal 一个插件可以实现多个goal，goal具备具体的功能
Execution 通过配置，决定在某个Phase执行哪些Goal
Project maven管理的目标：软件工程，小的工程可以聚合成大工程
PackageType 为了便于管理工程，按照构建目标区分成不同的工程类型，如jar，war，ear等
Dependency 依赖，project之间存在依赖关系
DependencyScope maven对依赖定义了不同的作用范围
Management 可以配置一个工程如何管理依赖关系
Repository 仓库，存放包，分为本地库和远程库
Build 构建的动作。使用maven管理工程，主要是指定将project构建到某个phase

Maven坐标简称GAV
groupId： 代表当前项目组织名称
artifactId：代表当前项目名称
version：代表当前项目的当前版本
scope: 属性我们需要了解其中的四种：compile / test / perovided / runtime。
compile：编译依赖范围,scope属性的默认值,表示在编译,测试,系统运行时 都需要此jar包，比如：log4j.jar。
test：测试依赖范围表示只是在测试的过程中需要用到此jar包，比如：junit.jar。
provided：已提供依赖范围,表示在编译,测试时需要用到此jar包,但是在正 式的运行环境中,不需要此jar包,因为运行的容器已经提供，比如：servlet-api.jar。
runtime：运行时依赖范围,表示只在运行需要用到此jar包，比如：数据库驱 动的jar包。

依赖冲突:当存在依赖冲突时,以就近原则来解决此类问题(同项目,以配置文件最下面为准/依赖传递就近以直接依赖为准)。
可选依赖:我们指定某个jar包的依赖时,还有个 optional 属性,默认值为 false，如果值为 true，则代表这个被引用的 jar 是可选依赖，不能往下传递。
依赖排除:如果maven02项目依赖maven01项目,但是maven01项目引用的一些jar包,maven02项目不需要,这个时候,可以配置exclusions标签进行排除,这就是排除依赖

a.生命周期的阶段phase与插件的目标goal相互绑定, 用以完成实际的构建任务. 而对于插件本身, 为了能够复用代码,它往往能够完成多个任务, 这些功能聚集在一个插件里,每个功能就是一个目标.
如:$ mvn compiler:compile: 冒号前是插件前缀, 后面是该插件目标(即: maven-compiler-plugin的compile目标).
而该目标绑定了default生命周期的compile阶段:
b.默认情况下 ，maven 会有内置绑定的 ，所以 我们用的时候会很简单，我们还可以自定义绑定插件到某个生命周期的阶段下

除了内置绑定以外, 自己还能够自定义将某个插件目标绑定到生命周期的某个阶段上. 如创建项目的源码包, maven-source-plugin插件的jar-no-fork目标能够将项目的主代码打包成jar文件, 可以将其绑定到verify阶段上:

org.apache.maven.plugins maven-source-plugin 3.0.0 attach-sources verify jar-no-fork

executions下每个execution子元素可以用来配置执行一个任务.

项目越来越复杂时(需要解决的问题越来越多、功能越来越重), 我们更倾向于将一个项目划分几个模块并行开发, 如: 将feedcenter-push项目划分为client、core和web三个模块, 而我们又想一次构建所有模块, 而不是针对各模块分别执行$ mvn命令. 于是就有了Maven的模块聚合 -> 将feedcenter-push作为聚合模块将其他模块聚集到一起构建:

4.0.0

com.vdian.feedcenter
feedcenter-push
pom
1.0.0.SNAPSHOT

feedcenter-push-client feedcenter-push-core feedcenter-push-web

通过在一个打包方式为pom的Maven项目中声明任意数量的module以实现模块聚合:
packaging: pom, 否则无法聚合构建.
modules: 实现聚合的核心,module值为被聚合模块相对于聚合POM的相对路径, 每个被聚合模块下还各自包含有pom.xml、src/main/java、src/test/java等内容, 离开聚合POM也能够独立构建(注: 模块所处目录最好与其artifactId一致).

模块继承

在面向对象中, 可以通过类继承实现复用. 在Maven中同样也可以创建POM的父子结构, 通过在父POM中声明一些配置供子POM继承来实现复用与消除重复:

dependencyManagement: 能让子POM继承父POM的配置的同时, 又能够保证子模块的灵活性: 在父POMdependencyManagement元素配置的依赖声明不会实际引入子模块中, 但能够约束子模块dependencies下的依赖的使用(子模块只需配置groupId与artifactId, 见下).
pluginManagement: 与dependencyManagement类似, 配置的插件不会造成实际插件的调用行为, 只有当子POM中配置了相关plugin元素, 才会影响实际的插件行为.

元素继承
子POM不需要定义模块groupId与version, 这是因为子POM默认会从父POM继承了如下元素:

groupId、version
dependencies
developers and contributors
plugin lists (including reports)
plugin executions with matching ids
plugin configuration
resources
因此所有的springframework都省去了version、junit还省去了scope, 而且插件还省去了executions与configuration配置, 因为完整的声明已经包含在父POM中.
优势: 当依赖、插件的版本、配置等信息在父POM中声明之后, 子模块在使用时就无须声明这些信息, 也就不会出现多个子模块使用的依赖版本不一致的情况, 也就降低了依赖冲突的几率. 另外如果子模块不显式声明依赖与插件的使用, 即使已经在父POM的dependencyManagement、pluginManagement中配置了, 也不会产生实际的效果.

推荐: 模块继承与模块聚合同时进行,这意味着, 你可以为你的所有模块指定一个父工程, 同时父工程中可以指定其余的Maven模块作为它的聚合模块. 但需要遵循以下三条规则:

注意点：

在所有子POM中指定它们的父POM;
将父POM的packaging值设为pom;
在父POM中指定子模块/子POM的目录.

parent元素内还包含一个relativePath元素, 用于指定父POM的相对路径, 默认…/pom.xml