Maven总结_-dmaven.test-CSDN博客

本文链接：https://blog.csdn.net/azhegps/article/details/84955213

【1】Maven的配置

Maven有两个settings.xml配置文件，一个是全局配置文件，一个是用户配置文件。%MAVEN_HOME%/conf/settings.xml 是maven全局的配置文件（默认）。~/.m2/settings.xml是用户的配置文件（默认没有该文件，需要将全局配置文件拷贝过来在进行修改），其中~表示当前用户路径C:\Users\[UserName]

注意：一般本地仓库的地址不使用默认配置，使用用户配置的仓库地址。用户级别的仓库在全局配置中一旦设置，全局配置将不再生效，转用用户所设置的仓库，否则使用全局配置文件中的默认路径仓库。

创建一个本地仓库目录，比如E:\08-repo\0707\repository；复制maven的全局配置文件到~/.m2目录下，即创建用户配置文件；修改maven的用户配置文件。

【2】创建Maven工程

【2-1】Maven的命令。需要在pom.xml所在目录中执行以下命令。

mvn compile：执行 mvn compile命令，完成编译操作。执行完毕后，会生成target目录，该目录中存放了编译后的字节码文件。

mvn clean：执行 mvn clean命令。执行完毕后，会将target目录删除。

mvn test：执行 mvn test命令，完成单元测试操作。执行完毕后，会在target目录中生成三个文件夹：surefire、surefire-reports（测试报告）、test-classes（测试的字节码文件），当然，生成报告或是case覆盖率需要如下这些配置等。

<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<groupId>maven</groupId>
<artifactId>maven-clover-plugin</artifactId>

mvn package：执行 mvn package命令，完成打包操作。执行完毕后，会在target目录中生成一个文件，该文件可能是jar、war

mvn install：执行 mvn install命令。完成将打好的jar包安装到本地仓库的操作，target下也有执行完毕后，会在本地仓库中出现安装后的jar包，方便其他工程引用。

mvn clean compile命令：执行 mvn clean compile组合指令，先执行clean，再compile，通常应用于上线前执行，清除测试类。

mvn clean test命令：执行 mvn clean test组合指令，先执行clean，再执行test，通常应用于测试环节。

mvn clean package命令：执行 mvn clean package组合指令，先执行clean，再执行package，将项目打包，通常应用于发布前。执行过程：

清理————清空环境

编译————编译源码

测试————测试源码

打包————将编译的非测试类打包

mvn clean install命令：执行 mvn clean install 组合指令，执行过程：

清理————清空环境

编译————编译源码

测试————测试源码

打包————将编译的非测试类打包

部署————将打好的包发布到资源仓库中

【3】Maven核心概念

groupId：定义当前Maven组织名称；artifactId：定义实际项目名称；version：定义当前项目的当前版本

【3-1】依赖范围

其中依赖范围scope 用来控制依赖和编译，测试，运行的classpath的关系. 主要的是三种依赖关系如下：

1.compile：默认编译依赖范围。对于编译，测试，运行三种classpath都有效

2.test：测试依赖范围。只对于测试classpath有效

3.provided：已提供依赖范围。对于编译，测试的classpath都有效，但对于运行无效。因为由容器已经提供，例如servlet-api

4.runtime:运行时的classpath有效。例如:jdbc驱动

【3-2】依赖传递。直接依赖和间接依赖

如果B中使用A，C中使用B，则称B是C的直接依赖，而称A是C的间接依赖。

C->B B->A

C直接依赖B C间接依赖A

【3-3】依赖范围对传递依赖的影响

左边第一列表示第一直接依赖范围，上面第一行表示第二直接依赖范围，中间的交叉单元格表示传递性依赖范围。

第二依赖的范围是compile，传递性依赖的范围与第一直接依赖的范围一致。
第二直接依赖的范围是test，依赖不会得以传递。
第二依赖的范围是provided，只传递第一直接依赖范围也为provided的依赖，且传递性依赖的范围同样为 provided；
第二直接依赖的范围是runtime，（除compile传递的依赖范围为runtime）传递性依赖的范围与第一直接依赖的范围一致。

【3-4】依赖冲突

如果直接与间接依赖中包含有同一个坐标不同版本的资源依赖，以直接依赖的版本为准。
如果直接依赖中包含有同一个坐标不同版本的资源依赖，则按照顺序，最后一个为准。

【3-5】可选依赖

<optional> true/false 是否可选，也可以理解为是否向下传递。在依赖中添加optional选项决定此依赖是否向下传递，如果是true则不传递，如果是false就传递，默认为false。

【3-6】排除依赖

排除依赖包中所包含的依赖关系，不需要添加版本号。如果在本次依赖中有一些多余的jar包也被传递依赖过来，如果想把这些jar包排除的话可以配置exclusions进行排除。

【4】生命周期

【4-1】maven生命周期就是为了对所有的构建过程进行抽象和统一。包括项目清理、初始化、编译、打包、测试、部署等几乎所有构建步骤。生命周期可以理解为构建工程的步骤。在Maven中有三套相互独立的生命周期，请注意这里说的是“三套”，而且“相互独立”，这三套生命周期分别是：

Clean Lifecycle：在进行真正的构建之前进行一些清理工作。
Default Lifecycle：构建的核心部分，编译，测试，打包，部署等等。
Site Lifecycle：生成项目报告，站点，发布站点。

再次强调一下它们是相互独立的，你可以仅仅调用clean来清理工作目录，仅仅调用site来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。

【4-2】Maven三大生命周期

【4-2-1】clean：清理项目

每套生命周期都由一组阶段(Phase)组成，我们平时在命令行输入的命令总会对应于一个特定的阶段。比如，运行mvn clean ，这个的clean是Clean生命周期的一个阶段。有Clean生命周期，也有clean阶段。Clean生命周期一共包含了三个阶段：

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

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

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

mvn clean 中的clean就是上面的clean，在一个生命周期中，运行某个阶段的时候，它之前的所有阶段都会被运行，也就是说，mvn clean 等同于 mvn pre-clean clean，如果我们运行 mvn post-clean ，那么 pre-clean，clean 都会被运行。这是Maven很重要的一个规则，可以大大简化命令行的输入。

【4-2-2】default：构建项目

Default生命周期是Maven生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。这里，只解释一些比较重要和常用的阶段：

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

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

【4-2-3】site：生成项目站点

Site生命周期

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

site 生成项目的站点文档

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

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

这里经常用到的是site阶段和site-deploy阶段，用以生成和发布Maven站点，这可是Maven相当强大的功能，Manager比较喜欢，文档及统计数据自动生成，很好看。

【4-3】Maven插件

Maven的核心仅仅定义了抽象的生命周期，具体的任务都是交由插件完成的。每个插件都能实现一个功能，每个功能就是一个插件目标。Maven的生命周期与插件目标相互绑定，以完成某个具体的构建任务。例如compile就是插件maven-compiler-plugin的一个插件目标。

【4-3-1】Maven编译插件

Tomcat插件
运行tomcat插件

tomcat:run 运行tomcat6（默认）

tomcat7:run 运行tomcat7（推荐，但是需要添加插件）

<groupId>org.apache.tomcat.maven</groupId>

<artifactId>tomcat7-maven-plugin</artifactId>

</configuration>

</plugin>

【4-3-2】继承

继承是为了消除重复，可以把很多相同的配置提取出来。例如：grouptId，version等

【4-3-2-1】创建父工程

父工程的packaging必须是pom

【4-3-2-2】创建子工程

创建方式有两种：

一种是创建新工程为子工程，在创建时设置父工程的GAV。

一种是修改原有的工程为子工程，在子工程的pom.xml文件中手动添加父工程的GAV。

现有工程继承父工程只需要在pom文件中添加parent节点即可。

【4-3-2-3】父工程统一依赖jar包

在父工程中对jar包进行依赖，在子工程中都会继承此依赖。

【4-3-2-4】父工程统一管理版本号

Maven使用dependencyManagement管理依赖的版本号。

注意：此处只是定义依赖jar包的版本号，并不实际依赖。如果子工程中需要依赖jar包还需要添加dependency节点。父工程：

子工程：

【4-3-2-5】父工程中版本号提取

当父工程中定义的jar包越来越多，找起来越来越麻烦，所以可以把版本号提取成一个属性集中管理。

【4-4】聚合

聚合一般是一个工程拆分成多个模块开发，每个模块是一个独立的工程，但是要是运行时必须把所有模块聚合到一起才是一个完整的工程，此时可以使用maven的聚合工程。

例如电商项目中，包括商品模块、订单模块、用户模块等。就可以对不同的模块单独创建工程，最终在打包时，将不同的模块聚合到一起。例如同一个项目中的表现层、业务层、持久层，也可以分层创建不同的工程，最后打包运行时，再聚合到一起。

【4-1-1】创建一个聚合工程

聚合工程的打包方式必须是pom，一般聚合工程和父工程合并为一个工程。

【4-1-2】创建持久层工程

第一步：在maven-web工程上，点击new –> project

第二步：next

【4-1-3】创建业务层工程

与持久层工程创建一样

【4-1-4】创建表现层工程

点击next，进行下面的页面

在maven-controller中添加web.xml和index.jsp

聚合之后的maven-web工程的pom文件内容如下：

【4-1-5】运行maven-web聚合工程

Tomcat7:run

注意：运行之前，需要将maven-parent工程安装到本地仓库中。

【5】Maven仓库管理

用来统一存储所有Maven共享构建的位置就是仓库。根据Maven坐标定义每个构建在仓库中唯一存储路径大致为：groupId/artifactId/version/artifactId-version.packaging。

【5-1】仓库的分类

【5-1】本地仓库

~/.m2/repository

每个用户只有一个本地仓库

【5-2】远程仓库

中央仓库：Maven默认的远程仓库，不包含版权资源

http://repo1.maven.org/maven2

私服：是一种特殊的远程仓库，它是架设在局域网内的仓库

【5-3】Maven私服

【5-3-1】安装Nexus

为所有来自中央仓库的构建安装提供本地缓存。

下载网站：http://nexus.sonatype.org/

安装版本：nexus-2.7.0-06.war

第一步：将下载的nexus的war包复制到tomcat下的webapps目录。

第二步：启动tomcat。nexus将在c盘创建sonatype-work目录【C:\Users\当前用户\sonatype-work\nexus】。

【5-3-2】Nexus的目录结构

【5-3-3】访问Nexus

访问URL: http://localhost:8080/nexus-2.7.0-06/

默认账号:用户名admin密码admin123

Nexus的仓库和仓库组

仓库有4种类型 :

group(仓库组)：一组仓库的集合
hosted(宿主)：配置第三方仓库（包括公司内部私服）
proxy(代理)：私服会对中央仓库进行代理，用户连接私服，私服自动去中央仓库下载jar包或者插件
virtual(虚拟)：兼容Maven1 版本的jar或者插件

Nexus的仓库和仓库组介绍:

3rd party: 一个策略为Release的宿主类型仓库，用来部署无法从公共仓库获得的第三方发布版本构建
Apache Snapshots: 一个策略为Snapshot的代理仓库，用来代理Apache Maven仓库的快照版本构建
Central: 代理Maven中央仓库
Central M1 shadow: 代理Maven1 版本中央仓库
Codehaus Snapshots: 一个策略为Snapshot的代理仓库，用来代理Codehaus Maven仓库的快照版本构件
Releases: 一个策略为Release的宿主类型仓库，用来部署组织内部的发布版本构件
Snapshots: 一个策略为Snapshot的宿主类型仓库，用来部署组织内部的快照版本构件
Public Repositories:该仓库组将上述所有策略为Release的仓库聚合并通过一致的地址提供服务

配置所有构建均从私服下载

在本地仓库的setting.xml中配置如下：

<id>nexus</id>

<url>http://localhost:8080/nexus-2.7.0-06/content/groups/public/</url>

</mirror>

</mirrors>

部署构建到Nexus
第一步：Nexus的访问权限控制

在本地仓库的setting.xml中配置如下：

<id>releases</id>

<username>admin</username>

<password>admin123</password>

</server>

<id>snapshots</id>

<username>admin</username>

<password>admin123</password>

</server>

第二步：配置pom文件

在需要构建的项目中修改pom文件

<id>releases</id>

<name>Internal Releases</name> <url>http://localhost:8080/nexus-2.7.0-06/content/repositories/releases/</url>

</repository>

<id>snapshots</id>

<name>Internal Snapshots</name> <url>http://localhost:8080/nexus-2.7.0-06/content/repositories/snapshots/</url>

</snapshotRepository>

</distributionManagement>

第三步：执行maven的deploy命令