转载于：https://blog.csdn.net/qq_34988624/article/details/86017515
1、maven是什么？
mavne定义：
maven是apache软件基金会下的一款自动化构建工具，专注于服务Java平台上的项目构建和依赖管理。
构建定义：
把动态的Web工程经过编译得到的编译结果部署到服务器上的整个过程。
编译：java源文件[.java]->编译->Classz字节码文件[.class]
部署：最终在sevlet容器中部署的不是动态web工程，而是编译后的文件
构建过程：
【清理项目】→【编译项目】→【测试项目】→【生成测试报告】→【打包项目】→【部署项目】
2、优缺点有哪些？
优点如下：
简化了项目依赖管理：
易于上手，对于新手可能一个"mvn clean package"命令就可能满足他的工作
便于与持续集成工具（jenkins）整合
便于项目升级，无论是项目本身升级还是项目使用的依赖升级。
有助于多模块项目的开发，一个模块开发好后，发布到仓库，依赖该模块时可以直接从仓库更新，而不用自己去编译。
maven有很多插件，便于功能扩展，比如生产站点，自动发布版本等
缺点如下：
maven是一个庞大的构建系统，学习难度大
maven采用约定优于配置的策略（convention over configuration），虽然上手容易，但是一旦出了问题，难于调试。
3、规约
/src/main/java/ java源码
/src/main/resource java配置文件，资源文件
/src/test/java/ java测试代码
/src/test/resource java测试配置文件，资源文件
/target 文件编译过程中生成的.class文件，jar，war等
pom.xnl 配置文件
Maven 要负责项目的自动化构建，以编译为例，Maven 要想自动进行编译，那么它必须知道 Java 的源文件保存在哪里，这样约定之后，不用我们手动指定位置，Maven 能知道位置，从而帮我们完成自动编译。
遵循 约定>>>配置>>>编码。即能进行配置的不要去编码指定，能事先约定规则的不要去进行配置。这样既减轻了劳动力，也能防止出错。
4、POM文件
基本信息
modelVersion：Maven模块版本
groupId：整个系统的名称
artifactId：子模块名称
packaging：
打包类型，可取值：jar,war等等，这个配置用于package的phase，具体可以参见package运行的时候启动的plugin，后面有机会我们会讲述如何配置打包的插件。
dependencies
依赖关系。pom之间存三种关系：继承、依赖、聚合。先讲依赖，这也是最重要的关系。
groupId：依赖项的groupId
artifactId：依赖项的artifactId
version：依赖项的版本
scope：依赖项的适用范围：compile，缺省值，适用于所有阶段，会随着项目一起发布。provided，类似compile，期望JDK、容器或使用者会提供这个依赖。如servlet.jar。runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。之前例子里的junit就只用在了test中。
exclusions：排除项目中的依赖冲突时使用。
scope就是依赖的范围
1、compile，默认值，适用于所有阶段（开发、测试、部署、运行），本jar会一直存在所有阶段。
2、provided，只在开发、测试阶段使用，目的是不让Servlet容器和你本地仓库的jar包冲突 。如servlet.jar。
3、runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
4、test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
5、system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。
排除依赖冲突
我们可能经常会遇到这样一个问题：我们的项目有两个依赖项：A & B，而且A和B同时依赖了C，但不是同一个版本。可以添加检查插件，然后运行：mvn project-info-reports:dependencies，查看依赖项报告。
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
</plugin>
</plugins>
</reporting>
如果我们需要在某个dependency中去除某个依赖项：
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>${struts.version}</version>
<exclusions>
<exclusion>
<groupId>org.freemarker</groupId>
<artifactId>freemarker</artifactId>
</exclusion>
</exclusions>
</dependency>
继承
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.cong</groupId>
<artifactId>parentTest</artifactId>
<version>1.0.0</version>
</parent>
聚合
我们可以通过一个大的项目来整合各个小的模块：
<modules>
<module>my-app</module>
</modules>
属性
属性表述类似于EL表达式，可以使用properties标签
<properties> <mysql.version>100</mysql.version> </properties>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysql.version}</version>
</dependency>
构建
build标签中可以包含很多插件，这些插件可以配置到项目的某些构建阶段，随着项目的构建进程发挥作用。Plugin的配置如下：
1 <pluginManagement> 2 <plugins> 3 <plugin> 4 <groupId>org.apache.tomcat.maven</groupId> 5 <artifactId>tomcat7-maven-plugin</artifactId> 6 <version>2.1</version> 7 <configuration> 8 <tomcat-url>http://localhost:8080/manager/html</tomcat-url> 9 <server>tomcat_localtest</server> 10 </configuration> 11 </plugin> 12 </plugins> 13 </pluginManagement>
我们可以看到同样要哟偶groupId、artifactId、version还有一些配置参数。
resource，指定你在Build时需要的资源文件：
1 <resources> 2 <resource> 3 <targetPath>WEB-INF/resource</targetPath> 4 <!-- 不对文件中的表达式进行处理 --> 5 <filtering>false</filtering> 6 <directory>${basedir}/src/test/resources</directory> 7 <includes> 8 <include>include.xml</include> 9 </includes> 10 <excludes> 11 <exclude>exclude.xml</exclude> 12 </excludes> 13 </resource> 14 </resources>
5、生命周期
maven中有三个独立的生命周期
1、Clean
2、Default
3、Site
每个生命周期都有这个特点：
不管用户要求执行的命令对应生命周期中的哪一个阶段，Maven都会自动从当前生命周期的最初位置开始执行，直到完成用户下达的指令
一个完整的项目构建过程通常包括清理、编译、测试、打包、集成测试、验证、部署等步骤，Maven从中抽取了一套完善的、易扩展的生命周期。Maven的生命周期是抽象的，其中的具体任务都交由插件来完成。Maven为大多数构建任务编写并绑定了默认的插件，如针对编译的插件：maven-compiler-plugin。用户也可自行配置或编写插件。
Maven有三套相互独立的生命周期，分别是clean、default和site。每个生命周期包含一些阶段，阶段是有顺序的，后面的阶段依赖于前面的阶段。
1、clean生命周期：清理项目，包含三个phase。
1）pre-clean：执行清理前需要完成的工作
2）clean：清理上一次构建生成的文件
3）post-clean：执行清理后需要完成的工作
2、default生命周期：构建项目，重要的phase如下。
1）validate：验证工程是否正确，所有需要的资源是否可用。
2）compile：编译项目的源代码。
3）test：使用合适的单元测试框架来测试已编译的源代码。这些测试不需要已打包和布署。
4）Package：把已编译的代码打包成可发布的格式，比如jar。
5）integration-test：如有需要，将包处理和发布到一个能够进行集成测试的环境。
6）verify：运行所有检查，验证包是否有效且达到质量标准。
7）install：把包安装到maven本地仓库，可以被其他工程作为依赖来使用。
8）Deploy：在集成或者发布环境下执行，将最终版本的包拷贝到远程的repository，使得其他的开发者或者工程可以共享。
3、site生命周期：建立和发布项目站点，phase如下
1）pre-site：生成项目站点之前需要完成的工作
2）site：生成项目站点文档
3）post-site：生成项目站点之后需要完成的工作
4）site-deploy：将项目站点发布到服务器
各个生命周期相互独立，一个生命周期的阶段前后依赖。
1、mvn clean
调用clean生命周期的clean阶段，实际执行pre-clean和clean阶段
2、mvn test
调用default生命周期的test阶段，实际执行test以及之前所有阶段
3、mvn clean install
调用clean生命周期的clean阶段和default的install阶段，实际执行pre-clean和clean，install以及之前所有阶段
6、插件
Maven 生命周期的每一个阶段的具体实现都是由 Maven 插件实现的。
插件通常提供了一个目标的集合，并且可以使用下面的语法执行：
<code>mvn [plugin-name]:[goal-name]</code>
插件类型
Maven 提供了下面两种类型的插件：
Build plugins 在构建时执行，并在 pom.xml 的 元素中配置。
Reporting plugins 在网站生成过程中执行，并在 pom.xml 的 元素中配置。
下面是一些常用插件的列表：
clean 构建之后清理目标文件。删除目标目录。
compiler 编译 Java 源文件。
surefile 运行 JUnit 单元测试。创建测试报告。
jar 从当前工程中构建 JAR 文件。
war 从当前工程中构建 WAR 文件。
javadoc 为工程生成 Javadoc。
antrun 从构建过程的任意一个阶段中运行一个 ant 任务的集合。
自定义插件
以Idea为例，创建工程选择 Maven，然后在模板中找到 maven-archetype-mojo，点击下一步，输入对应的参数，如：com.qchery/ekjar-maven-plugin/1.0-SNAPSHOT，最后点击完成即可创建一个简单的 Mojo（Maven plain Old Java Object）工程。
创建完成后，工程内会生成对应的 pom.xml 文件。其内容比较简单，与普通 Maven 工程的 pom.xml 基本一致，只是自动添加了对 maven-plugin-api 的依赖，这个依赖里面会包含一些 Mojo 的接口与抽象类，在后续编写具体的 Mojo 时再进行详细讲解。
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-plugin-api</artifactId>
<version>2.0</version>
</dependency>
与普通 pom.xml 文件一个重要的不同之处是它的打包方式：
<packaging>maven-plugin</packaging>
@Mojo(name="sogoucloud",defaultPhase= LifecyclePhase.PACKAGE)
public class SogoucloudMojo extends AbstractMojo {
@Parameter
private String msg;
@Parameter
private List<String> options;
@Parameter(property = "args")
private String args;
public void execute() throws MojoExecutionException,MojoFailureException{
System.out.println("hello sogoucloud:"+msg);
System.out.println("hello sogoucloud:"+options);
System.out.println("hello sogoucloud:"+args);
}
}
@goal CustomMavenMojo：表示该插件的服务目标
@phase compile：表示该插件的生效周期阶段
@requiresProject false：表示是否依托于一个项目才能运行该插件
@parameter expression="${name}"：表示插件参数，使用插件的时候会用得到
@required:代表该参数不能省略
打包 mvn clean install ,安装到仓库，便于被其他项目引用
然后，新建另一个maven web项目，引入前面的插件
使用，mvn install -Dargs=aaa，将这个maven项目install起来，就可以看到之前传的参数了
7、命令
执行maven命令必须进入到pom.xml的目录中进行执行
maven 命令的格式为 mvn [plugin-name]:[goal-name]，可以接受的参数如下。
-D 指定参数，如 -Dmaven.test.skip=true 跳过单元测试；
-P 指定 Profile 配置，可以用于区分环境；
-e 显示maven运行出错的信息；
-o 离线执行命令,即不去远程仓库更新包；
-X 显示maven允许的debug信息；
-U 强制去远程更新snapshot的插件或依赖，默认每天只更新一次。
创建maven项目：mvn archetype:create
指定 group： -DgroupId=packageName
指定 artifact：-DartifactId=projectName
创建web项目：-DarchetypeArtifactId=maven-archetype-webapp
创建maven项目：mvn archetype:generate
验证项目是否正确：mvn validate
maven 打包：mvn package
只打jar包：mvn jar:jar
生成源码jar包：mvn source:jar
产生应用需要的任何额外的源代码：mvn generate-sources
编译源代码： mvn compile
编译测试代码：mvn test-compile
运行测试：mvn test
运行检查：mvn verify
清理maven项目：mvn clean
生成eclipse项目：mvn eclipse:eclipse
清理eclipse配置：mvn eclipse:clean
生成idea项目：mvn idea:idea
安装项目到本地仓库：mvn install
发布项目到远程仓库：mvn:deploy
在集成测试可以运行的环境中处理和发布包：mvn integration-test
显示maven依赖树：mvn dependency:tree
显示maven依赖列表：mvn dependency:list
下载依赖包的源码：mvn dependency:sources
安装本地jar到本地仓库：mvn install:install-file -DgroupId=packageName -DartifactId=projectName -Dversion=version -Dpackaging=jar -Dfile=path
启动tomcat：mvn tomcat:run
启动jetty：mvn jetty:run
运行打包部署：mvn tomcat:deploy
撤销部署：mvn tomcat:undeploy
启动web应用：mvn tomcat:start
停止web应用：mvn tomcat:stop
重新部署：mvn tomcat:redeploy
部署展开的war文件：mvn war:exploded tomcat:exploded
8、仓库
maven的仓库只有两大类：
本地仓库
远程仓库，在远程仓库中又分成了3种：
中央仓库
私服
其它公共库
Maven会先搜索本地仓库（repository），发现本地没有然后从远程仓库（中央仓库）获取。但中央仓库只有一个，最好从其镜象处下载。国内可以用阿里云下的服务器。也有通过nexus搭建的私服进行获取的具体参考nexus的创建和连接。
maven中的仓库分为两种，snapshot快照仓库和release发布仓库。snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。定义一个组件/模块为快照版本，只需要在pom文件中在该模块的版本号后加上-SNAPSHOT即可(注意这里必须是大写)，如下：
<groupId>cc.mzone</groupId>
<artifactId>m1</artifactId>
<version>0.1-SNAPSHOT</version>
<packaging>jar</packaging>
maven2会根据模块的版本号(pom文件中的version)中是否带有-SNAPSHOT来判断是快照版本还是正式版本。如果是快照版本，那么在mvn deploy时会自动发布到快照版本库中，会覆盖老的快照版本，而在使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本，那么在mvn deploy时会自动发布到正式版本库中，而使用正式版本的模块，在不更改版本号的情况下，编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。
所以，我们在开发阶段，可以将公用库的版本设置为快照版本，而被依赖组件则引用快照版本进行开发，在公用库的快照版本更新后，我们也不需要修改pom文件提示版本号来下载新的版本，直接mvn执行相关编译、打包命令即可重新下载最新的快照库了，从而也方便了我们进行开发。
私服
私服是一种特殊的远程仓库，它是架设在局域网内的仓库服务，私服代理广域网上的远程仓库，供局域网内的Maven用户使用。当Maven需要下载构件的时候，它从私服请求，如果私服上不存在该构件，则从外部的远程仓库下载，缓存在私服上之后，再为Maven的下载请求提供服务。我们还可以把一些无法从外部仓库下载到的构件上传到私服上。
Maven私服的 个特性：
1.节省自己的外网带宽：减少重复请求造成的外网带宽消耗
2.加速Maven构件：如果项目配置了很多外部远程仓库的时候，构建速度就会大大降低
3.部署第三方构件：有些构件无法从外部仓库获得的时候，我们可以把这些构件部署到内部仓库(私服)中，供内部maven项目使用
4.提高稳定性，增强控制：Internet不稳定的时候，maven构建也会变的不稳定，一些私服软件还提供了其他的功能
5.降低中央仓库的负荷：maven中央仓库被请求的数量是巨大的，配置私服也可以大大降低中央仓库的压力
当前主流的maven私服：
1.Apache的Archiva
2.JFrog的Artifactory
3.Sonatype的Nexus
9、项目构建过程
【清理项目】→【编译项目】→【测试项目】→【生成测试报告】→【打包项目】→【部署项目】
10、Maven有哪些优点和缺点
优点如下：
简化了项目依赖管理：
易于上手，对于新手可能一个"mvn clean package"命令就可能满足他的工作
便于与持续集成工具（jenkins）整合
便于项目升级，无论是项目本身升级还是项目使用的依赖升级。
有助于多模块项目的开发，一个模块开发好后，发布到仓库，依赖该模块时可以直接从仓库更新，而不用自己去编译。
maven有很多插件，便于功能扩展，比如生产站点，自动发布版本等
缺点如下：
maven是一个庞大的构建系统，学习难度大
maven采用约定优于配置的策略（convention over configuration），虽然上手容易，但是一旦出了问题，难于调试。
当依赖很多时，m2eclipse 老是搞得Eclipse很卡。
中国的网络环境差，很多repository无法访问，比如google code， jboss 仓库无法访问等。
11、Maven坐标
一般maven使用[groupID,artifactId,version，packaging]来表示一个项目的某个版本，有时还会使用classifier来表示项目的附属构建，常见的附属构建有javadoc和sources包。
12、Maven常见的依赖范围有哪些?
compile:编译依赖，默认的依赖方式，在编译（编译项目和编译测试用例），运行测试用例，运行（项目实际运行）三个阶段都有效，典型地有spring-core等jar。
test:测试依赖，只在编译测试用例和运行测试用例有效，典型地有JUnit。
provided:对于编译和测试有效，不会打包进发布包中，典型的例子为servlet-api,一般的web工程运行时都使用容器的servlet-api。
runtime:只在运行测试用例和实际运行时有效，典型地是jdbc驱动jar包。
system: 不从maven仓库获取该jar,而是通过systemPath指定该jar的路径。
import: 用于一个dependencyManagement对另一个dependencyManagement的继承。
13、我们经常使用“Mvn Clean Package”命令进行项目打包，请问该命令执行了哪些动作来完成该任务？
在这个命令中我们调用了maven的clean周期的clean阶段绑定的插件任务，以及default周期的package阶段绑定的插件任务
默认执行的任务有（maven的术语叫goal, 也有人翻译成目标，我这里用任务啦）：
maven-clean-plugin:clean->
maven-resources-plugin:resources->
maven-compile-plugin:compile->
mavne-resources-plugin:testResources->
maven-compile-plugin:testCompile->
maven-jar-plugin:jar
14、依赖的解析机制
解析发布版本：如果本地有，直接使用本地的，没有就向远程仓库请求。
解析快照版本：合并本地和远程仓库的元数据文件-groupId/artifactId/version/maven-metadata.xml，这个文件存的版本都是带时间戳的，将最新的一个改名为不带时间戳的格式供本次编译使用。
解析版本为LATEST,RELEASE，过于复杂，且解析的结果不稳定， 不推荐在项目中使用，感兴趣的同学自己去研究，简而言之就是合并groupId/artifactId/maven-metadata.xml找到对应的最新版本和包含快照的最新版本。
15、插件的解析机制
当我们输入"mvn dependency:tree"这样的指令，解析的步骤为：
解析groupID:
maven使用默认的groupID:"org.apache.maven.plugins"或者"org.codehaus.mojo"
解析artifactId(maven的官方叫做插件前缀解析策略)
合并该groupId在所有仓库中的元数据库文件（maven-metadata-repository.xml），比如maven官方插件的元数据文件所在的目录为org\apache\maven\plugins，该文件下有如下的条目
<plugin>
<name>Maven Dependency Plugin</name>
<prefix>dependency</prefix>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
通过比较这样的条目，我们就将该命令的artifactId解析为maven-dependency-plugin
解析version
如果你在项目的pom中声明了该插件的版本，那么直接使用该版本的插件，否则合并所有仓库中groupId/artifactId/maven-metadata-repository.xml，找到最新的发布版本。
对于非官方的插件，有如下两个方法可以选择：
1）使用groupId:artifactId:version:goal 来运行，好长~~~~~~~~~~
2）在Settings.xml中添加pluginGroup项，这样maven不能在官方的插件库中解析到某个插件，那么就可以去你配置的group下查找啦。
16、多模块如何聚合
配置一个打包类型为pom的聚合模块，然后在该pom中使用<module>元素声明要聚合的模块
17、对于一个多模块项目，如果管理项目依赖的版本
通过在父模块中声明dependencyManagement和pluginManagement， 然后让子模块通过<parent>元素指定父模块，这样子模块在定义依赖是就可以只定义groupId和artifactId，自动使用父模块的version,这样统一整个项目的依赖的版本。
18、一个项目的依赖来源于不同的组织，可能这些依赖还会依赖别的Jar包，如何保证这些传递依赖不会引起版本冲突。
使用<dependency>的<exclusion>元素将会引起冲突的元素排除。
19、常见的Maven私服的仓库类型。
（宿主仓库）hosted repository, （代理仓库）proxy repository, （仓库组）group repository
20、如何查询一个插件有哪些目标（Goal）
mvn help:describe -Dplugin=groupId:artifactId
from: http://www.javacoder.cn/?p=211
原文：https://blog.csdn.net/qq_34988624/article/details/86017515
版权声明：本文为博主原创文章，转载请附上博文链接！