maven必知必会知识汇总
1.mvn生命周期:
生命周期（lifecycle）由各个阶段组成，每个阶段由maven的插件plugin来执行完成。
- clean阶段：是独立的一个阶段，功能就是清除工程目前下的target目录，对应的插件是 maven-clean-plugin:2.5
- resource阶段：利用resouce插件把项目需要的配置文件拷贝到指定的目录，默认是拷贝src\main\resources目录下的件到target\classes目录下，当然可以自己来配置源目录和输出目录,一般不单独执行
- compile阶段：compile插件执行时先调用resouces插件，功能就是把src\main\java源码编译成字节码生成class文件，并把编译好的class文件输出到target\classes目录下
- testResources阶段和testCompile阶段：单元测试所用的compile和resources插件和主代码是相同的，但执行的目标不行，目标testCompile和testResources是把src\test\java下的代码编译成字节码输出到target\test-classes，同时把src\test\resources下的配置文件拷贝到target\test-classes
- test阶段：主要用到了插件maven-surefire-plugin:2.12.4，它是执行单元测试类的，如果单元测试不通行，构建会失败，在编译正式的项目时可以使用mvn -Dmaven.test.skip=true 来跳过测试类的编译和运行过程。mvn test可以单独执行，但是这个命令其实是包括了resources、compile、testResources、testCompile、test这几个阶段
- package阶段：这个插件是把class文件、配置文件打成一个jar(war或其它格式)包。依赖包是不在jar里面的，需要建立lib目录，且jar和lib目录在同级目录。常用的打包插件有maven-jar-plugin、maven-assembly-plugin、maven-shade-plugin三种
- install阶段
- deploy阶段
2.mvn的常用命令:
mvn –version：显示版本信息
mvn clean：清理项目生产的临时文件,一般是模块下的target目录
mvn compile：编译源代码，一般编译模块下的src/main/java目录
mvn package：项目打包工具,会在模块下的target目录生成jar或war等文件
mvn test：测试命令,或执行src/test/java/下junit的测试用例.
mvn install：将打包的jar/war文件复制到你的本地仓库中,供其他模块使用
mvn deploy：将打包的文件发布到远程参考,提供其他人员进行下载依赖
mvn site：生成项目相关信息的网站
mvn eclipse:eclipse：将项目转化为Eclipse项目，方便直接导入
mvn dependency:tree：打印出项目的整个依赖树
mvn archetype:generate：创建Maven的普通java项目
mvn tomcat:run：在tomcat容器中运行web应用(eclipse中的tomcat经常会出现不同步更新的情况)
mvn jetty:run：调用 Jetty 插件的 Run 目标在 Jetty Servlet 容器中启动 web 应用
注意：运行maven命令的时候，首先需要定位到maven项目的目录，也就是项目的pom.xml文件所在的目录。否则，必须通过参数来指定项目的目录。
mvn compile实际上是先定位到compile这一生命周期阶段，然后再根据绑定关系调用maven-compiler-plugin的compile目标
-D 传入属性参数
mvn package -Dmaven.test.skip=true：打包的时候跳过单元测试
mvn deploy-Dmaven.test.skip=true：部署项目并跳过单元测试
可以对pom.xml中的properties的值进行替换指定：
defaultattr
执行mvn -Dattr=newattr clean package，则pom.xml内attr的实际值将被替换成newattr
-P 使用指定的Profile配置，实现按不同环境进行打包部署（区分生产和正式）
如在pom.xml中设置：
dev
dev
true
qa
qa
pre
pre
prod
prod
......
config/${env}.properties
src/main/resources
true
......
mvn package -P dev：使用Id为“dev”的profile进行打包
-e 显示maven运行出错的信息
-o 离线执行命令,即不去远程仓库更新包
-X 显示maven允许的debug信息
-U 强制去远程更新snapshot的插件或依赖，默认每天只更新一次
mvn archetype:generate -DarchetypeCatalog=internal
该命令会以交互的模式创建maven项目，不需要像archetype:create（已淘汰）那样在后面跟一堆参数。maven默认会从远程服务器上获取archetype元数据，由于中央仓库的archetype太多（几千个）而造成程序的阻滞，加入-DarchetypeCatalog=internal参数则可以避免，只使用内置的原型就够了。然后maven会告诉你，archetype没有指定，默认使用maven-archetype-quickstart（相当于一个“HelloWorld”模板），或者从控制台列表中选择一个可用的原型，然后会依次提醒你输入groupId、artifactId、version(默认1.0-SNAPSHOT)以及创建的第一个包名。
3.mvn命令总结
mvn clean package依次执行了clean、resources、compile、testResources、testCompile、test、jar(打包)等７个阶段。
mvn clean install依次执行了clean、resources、compile、testResources、testCompile、test、jar(打包)、install等8个阶段。
mvn clean deploy依次执行了clean、resources、compile、testResources、testCompile、test、jar(打包)、install、deploy等９个阶段。
package命令完成了项目编译、单元测试、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
install命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库
deploy命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库和远程maven私服仓库
4.mvn的仓库
maven仓库包括本地仓库和远程仓库。优先从本地仓库（本地仓库默认地址为：${user.home}/.m2/repository）中寻找相关构件，远程仓库中的构件下载到本地仓库使用。中央仓库是 Maven 核心自带的远程仓库，默认地址：http://repo1.maven.org/maven2 。
私服是架设在本机或局域网中的一种特殊的远程仓库，通过私服可以方便的管理其它所有的外部远程仓库。
5.mvn的其它内容
- 依赖范围scope
compile：编译依赖范围，默认值。此选项对编译、测试、运行三种 classpath 都有效，如 hibernate-core-3.6.5.Final.jar，表明在编译、测试、运行的时候都需要该依赖
test：测试依赖范围。只对测试有效，表明只在测试的时候需要，在编译和运行时将无法使用该类依赖，如 junit；
provided：已提供依赖范围。编译和测试有效，运行无效。如 servlet-api ，在项目运行时，tomcat 等容器已经提供，无需 Maven 重复引入；
runtime：运行时依赖范围。测试和运行有效，编译无效。如 jdbc 驱动实现，编译时只需接口，测试或运行时才需要具体的 jdbc 驱动实现；
system：系统依赖范围。和 provided 依赖范围一致，需要通过 显示指定，且可以引用环境变量；
import：导入依赖范围。使用该选项，通常需要 pom，将目标 pom 的 dependencyManagement 配置导入合并到当前 pom 的 dependencyManagement 元素。 - 传递依赖
如果我们的项目引用了一个Jar包，而该Jar包又引用了其他Jar包，那么在默认情况下项目编译时，Maven会把直接引用和简洁引用的Jar包都下载到本地。 - 排除依赖
如果我们只想下载直接引用的Jar包，那么需要在pom.xml中做如下配置：(将需要排除的Jar包的坐标写在其中)
cn.missbe.web.search
resource-search
pom
1.0-SNAPSHOT
- 依赖冲突
若项目中多个Jar同时引用了相同的Jar时，会产生依赖冲突，但Maven采用了两种避免冲突的策略，因此在Maven中是不存在依赖冲突的。
短路优先：
本项目——>A.jar——>B.jar——>X.jar
本项目——>C.jar——>X.jar
若本项目引用了A.jar，A.jar又引用了B.jar，B.jar又引用了X.jar，并且C.jar也引用了X.jar。在此时，Maven只会引用引用路径最短的Jar。
声明优先：
若引用路径长度相同时，在pom.xml中谁先被声明，就使用谁。 - 聚合
将多个项目同时运行就称为聚合。只需在pom中作如下配置即可实现聚合：
web-connection-pool
web-java-crawler
- 继承
在聚合多个项目时，如果这些被聚合的项目中需要引入相同的Jar，那么可以将这些Jar写入父pom中，各个子项目继承该pom即可。
实现继承：
1） 父pom配置：将需要继承的Jar包的坐标放入标签即可。
cn.missbe.web.search
resource-search
pom
1.0-SNAPSHOT
2） 子pom配置：
父pom所在项目的groupId
父pom所在项目的artifactId
父pom所在项目的版本号
resource-search
cn.missbe.web.search
1.0-SNAPSHOT
dependencyManagement和dependencies区别：
1)dependencies:自动引入声明在dependencies里的所有依赖，并默认被所有的子项目继承。如果项目中不写依赖项，则会从父项目继承（属性全部继承）声明在父项目dependencies里的依赖项。
2)dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要的依赖。如果不在子项目中声明依赖，是不会从父项目中继承的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。同时dependencyManagement让子项目引用依赖，而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在这个dependencyManagement元素中指定的版本号,实现所有子项目使用的依赖项为同一版本。
3）dependencyManagement 中的 dependencies 并不影响项目的依赖项；而独立dependencies元素则影响项目的依赖项。只有当外层的dependencies元素中没有指明版本信息时，dependencyManagement 中的 dependencies 元素才起作用。一个是项目依赖，一个是maven项目多模块情况时作依赖管理控制的。
附：
comipe 默认，编译 测试 打包都依赖，有传递性，会被打到包里；
provided 编译 测试依赖，有传递性，不会被打到包里。例如servlet-api有容器提供，没必要打到包里。 但是继承性，上面的情况，如果需要统一配置一个组织的通用的provided依赖，可以使用parent，然后在所有工程中继承。
test 测试时依赖，没有传递性，不会被打到包里。如测试包下的测试。
runtime 测试和运行时候依赖，有传递性，会打到包里。如jdbc驱动。
本文参考文章地址：https://www.cnblogs.com/Eilen/p/6558591.html
本文首发于我的个人博客：呆狗个人博客，转载请标明出处
文章参考链接均附在文末，感谢作者的分享和付出，使我们得以站在巨人的肩膀上继续前行
小白一枚，如果文章对您有帮助或者有什么不对的地方，欢迎关注收藏留言哦