活久见！64 张图带你 Maven 实战通关（二）

Maven 的常用命令

mvn compile 编译,将Java 源程序编译成 class 字节码文件。
mvn test 测试，并生成测试报告
mvn clean 将以前编译得到的旧的 class 字节码文件删除
mvn pakage 打包,动态 web工程打 war包，Java工程打 jar 包。
mvn install 将项目生成 jar 包放在仓库中，以便别的模块调用

compile:将Java 源程序编译成 class 字节码文件。

第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...

第二步：在第一步执行完后弹出来的对话框中，输入 compile，然后点击 Run 按钮

第三步：查看控制台

第四步：在 target 目录下，我们会发现编译生成的 class 文件

test:测试，并生成测试报告

• 第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...,然后在弹出框中输入 test，或者选择 pom.xml 文件，右键--->Run As------>6 Maven test
  
• 第二步：查看控制台，分析测试程序，我们传入的参数是Tom，而我们希望的是maven，很显然是不相等的，那么测试失败　

如果测试类 HelloTest.java改为如下：

重新执行 mvn test 命令，控制台如下：　

生成的测试报告可以在如下目录查看：target/surefire-reports

mvn clean 将以前编译得到的旧的 class 字节码文件删除

• 第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...,然后在弹出框中输入 clean

或者选择 pom.xml 文件，右键--->Run As------>3 Maven clean，如下图

• 第二步：查看控制台　

• 第三步：发现 mvn compile 编译好的文件这时已经清除了

mvn pakage 打包,动态 web工程打 war包，Java工程打 jar 包。

• 第一步：选择 pom.xml 文件，右键--->Run As ---->2 Maven build...,然后在弹出框中输入 package

• 第二步：查看控制台
• 第三步：进入到 target 目录，会发现打出来的 jar 包

mvn install 将项目生成 jar 包放在仓库中，以便别的模块调用

Maven 坐标的概念和依赖管理

我们知道 maven 能帮我们管理jar包，那么它是怎么管理的呢？我们下面就来讲解一下

什么是坐标

「数学中的坐标」

在平面上，使用 X 、Y 两个向量可以唯一的定位平面中的任何一个点

在空间中，使用 X、Y、Z 三个向量可以唯一的定位空间中的任意一个点

「Maven 中的坐标」

俗称 gav：使用下面三个向量子仓库中唯一定位一个 Maven 工程

在项目中的 pom.xml 文件中，我们可以看到下面 gav 的定义

• groupid:公司或组织域名倒序 ：com.ys.maven
• artifactid:模块名，也是实际项目的名称：Maven_05
• version:当前项目的版本：0.0.1-SNAPSHOT

「Maven 坐标和仓库，jar 包的关系」

什么是仓库，后面我们会详细讲解，现在你只需要知道是 Maven 用来存放 jar 包的地方。

那么依照上面定义的 gav，我们执行 mvn -install 命令，会出现什么情况呢？

首先进入到我们上面讲过的 settings.xml 文件配置的仓库目录。

将我们上面配置的 gav 向量组合起来就是目录：

com/ys/maven/Maven_05/0.0.1-SNAPSHOT/Maven_05-0.0.1-SNAPSHOT.jar

其次，我们观察打出来的 jar 包：Maven_05-0.0.1-SNAPSHOT.jar，也就是 artifactid-version.jar

Maven 依赖

什么是依赖？相信有过一定开发经验的人知道，每当我们需要使用某个框架时，比如 SpringMVC，那么我们需要导入相应的 jar 包，但是手动导入包的时候，往往会漏掉几个 jar 包，那么在使用该框架的时候系统就会报错。那么我们就说导入的包与未导入的包存在依赖关系。而使用 Maven,我们只需要在 pom.xml 文件中进行相应的配置，它就会帮助我们自动管理 jar 包之间的依赖关系。那么它是怎么管理的呢，接下来我们会详细讲解。

依赖的详细配置

我们以 Junit 为例，在 pom.xml 文件中进行详细而完整的配置。

<project>

• dependencies：一个 pom.xml 文件中只能存在一个这样的标签。用来管理依赖的总标签。
  
• dependency: 包含在 dependencies 标签中，可以有无数个，每一个表示一个依赖
  
• groupId、artifactId 和 version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven根 据坐标才能找到需要的依赖。
  
• type：依赖的类型，对应于项目坐标定义的 packaging。大部分情况下，该元素不必声明，其默认值是 jar。
  
• scope：依赖的范围，默认值是 compile。后面会进行详解。
  
• optional：标记依赖是否可选。
  
• exclusions：用来排除传递性依赖，后面会进行详细介绍。

依赖的范围 scope

先放一张图

一般情况下，我们对前面三个依赖用的比较多。下面的主程序表示 maven 目录结构 src/main/java.测试程序目录结构为：src/test/java

「compile 范围依赖」

对主程序是否有效：有效

对测试程序是否有效：有效

是否参与打包：参与

是否参与部署：参与

典型例子：log4j

「test 范围依赖」

对主程序是否有效：无效

对测试程序是否有效：有效

是否参与打包：不参与

是否参与部署：不参与

典型例子：Junit

「provided 范围依赖」

对主程序是否有效：有效

对测试程序是否有效：有效

是否参与打包：不参与

是否参与部署：不参与

典型例子：servlet-api.jar，一般在发布到 服务器中，比如 tomcat，服务器会自带 servlet-api.jar 包，所以provided 范围依赖只在编译测试有效。

「runtime 范围依赖」：在测试、运行的时候依赖，在编译的时候不依赖。例如：JDBC 驱动，项目代码只需要 jdk 提供的 jdbc 接口，只有在执行测试和运行项目的时候才需要实现 jdbc 的功能。

接下来我们举几个例子在工程中实际去理解：

「test 依赖和 compile 依赖的区别：」

首先我们在 pom.xml 文件中配置，Junit 的 test 依赖

我们在主程序中去导入 Junit 的包，然后进行 mvn -compile 编译，很明显，test 范围的在主程序中无效，故编译会报错。

我们在 src/main/java 包下新建 MavenTest.java,并导入 Junit 包

然后执行 mvn -compile 操作，如下图报错信息：

我们将 Junit 的依赖范围改为 compile，然后执行 mvn -compile　

发现 mvn -compile 没有报错了。　　

依赖的传递

比如我们创建三个 Maven 工程，maven-first，maven-second 以及 maven-third，而 third 依赖于 second，second 又依赖于 first，那么我们说 second 是 third 的第一直接依赖，first 是 second 的第二直接依赖。而 first 是 third 的间接依赖。

依赖之间的传递如下图：「第一列表示第一直接依赖，第一行表示第二直接依赖」

总结

当第二依赖的范围是 compile 的时候，传递性依赖的范围与第一直接依赖的范围一致。

当第二直接依赖的范围是 test的时候，依赖不会得以传递。

当第二依赖的范围是 provided 的时候，只传递第一直接依赖范围也为provided 的依赖，且传递性依赖的范围同样为 provided；

当第二直接依赖的范围是 runtime 的时候，传递性依赖的范围与第一直接依赖的范围一致，但compile例外，此时传递的依赖范围为 runtime；

我们这里举个例子来看：

第二依赖范围是 test

Maven_first 的pom.xml 文件如下：

然后 Maven_second 依赖 Maven_fisrt，Maven_third 依赖 Maven-second，其pom.xml 文件如下

Maven_second的 pom.xml

Maven_third 的 pom.xml

我们发现在 Maven_third 和 Maven_second 都没有 Maven_first 引入的 Junit 包，正好符合上面总结的第二点：当第二直接依赖的范围是test的时候，依赖不会得以传递。

第二依赖范围是 compile

如果我们将 Maven_first 的Junit 改为 compile，那么将会符合上面总结的第一点：当第二依赖的范围是compile的时候，传递性依赖的范围与第一直接依赖的范围一致。