Maven的依赖管理

（一）Maven常用命令

-v:查询Maven版本

本命令用于检查Maven是否安装成功。Maven安装完成之后，在命令行输入mvn -v，若出现Maven信息，则说明安装成功。

compile：编译命令

将java源文件编译成class文件

test:测试项目命令

执行test目录下的测试用例

package:打包命令

将项目打成jar包

clean:删除target文件夹命令

install:安装命令

将当前项目放到Maven的本地仓库中。供其他项目使用

（二）Maven中依赖的传递

Jar能依赖jar √

War能依赖 jar √ 最常见！！！！

Jar能依赖war √！！！但是不可能出现

War能依赖war √ 也算常见

Maven 中最关键的部分，我们使用 Maven 最主要的就是使用它的依赖管理功能。要理解和掌握 Maven的依赖管理，我们只需要解决一下几个问题：

1、依赖的目的是什么

当 A jar 包用到了 B jar 包中的某些类时，A 就对 B 产生了依赖，这是概念上的描述。那么如何在项目中以依赖的方式引入一个我们需要的 jar 包呢？

答案非常简单，就是使用 dependency 标签指定被依赖 jar 包的坐标就可以了。

<groupId>com.offcn.Maven</groupId>

<artifactId>Hello</artifactId>

<version>0.0.1-SNAPSHOT</version>

<scope>compile</scope>

</dependency>

2、依赖的范围scope

大家注意到上面的依赖信息中除了目标 jar 包的坐标还有一个 scope 设置，这是依赖的范围。依赖的范

围有几个可选值，我们用得到的是：compile、test、provided 三个。

（1）从项目结构角度理解 compile 和 test 的区别

对于 HelloFriend 来说，Hello 就是服务于主程序的，junit 是服务于测试程序的。HelloFriend 主程序需要 Hello 是非常明显的，测试程序由于要调用主程序所以也需要 Hello，所以compile 范围依赖对主程序和测试程序都应该有效。HelloFriend 的测试程序部分需要 junit 也是非常明显的，而主程序是不需要的，所以 test 范围依赖

仅仅对于主程序有效

（2）从开发和运行这两个不同阶段理解 compile 和 provided 的区别

（3）有效性总结

（4）依赖的传递性

A 依赖 B，B 依赖 C，A 能否使用 C 呢？那要看 B 依赖 C 的范围是不是 compile，如果是则可用，否则不可用

（三）依赖的排除

如果我们在当前工程中引入了一个依赖是 A，而 A 又依赖了 B，那么 Maven 会自动将 A 依赖的 B 引入当前工程，但是个别情况下 B 有可能是一个不稳定版，或对当前工程有不良影响。这时我们可以在引入 A 的时候将 B 排除。

情景举例

pom.xml文件中的配置如下：

排除后的效果

（三）jar包冲突的解决

1：就近原则

Jar3 》》jar2（junit）》》jar1（junit）:引用jar2中的junit

2：配置文件从上而下加载，所以优先引用最上面的依赖

1、路径最短者优先

2、路径相同时先声明者优先

这里“声明”的先后顺序指的是 dependency 标签配置的先后顺序

四：maven项目管理

（一）统一版本控制

统一管理所依赖 jar 包的版本,在开发中对同一个框架的一组 jar 包最好使用相同的版本。不同版本的jar包之间存在很大冲突，为了方便升级框架，可以将 jar 包的版本信息统一提取出来，进行统一的管理。

1、统一声明版本号

<offcn.Spring.version>4.1.1.RELEASE</offcn.Spring.version>

</properties>

其中 offcn.Spring.version 部分是自定义标签

2、引用前面声明的版本号

<groupId>org.Springframework</groupId>

<artifactId>Spring-core</artifactId>

<version>${offcn.Spring.version}</version>

</dependency>

……

</dependencies>

3、其他用法

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

（二） Maven项目的继承

为什么需要继承机制？

由于非 compile 范围的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。例如

此时如果项目需要将各个模块的junit版本统一为4.9，那么到各个工程中手动修改无疑是非常不可取的。使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理

继承的测试

1、创建父工程

创建父工程和创建一般的 Java 工程操作一致，唯一需要注意的是：打包方式处要设置为 pom。

2、在子工程中引用父工程

<relativePath>从当前目录到父项目的 pom.xml 文件的相对路径</relativePath>

</parent>

<groupId>com.offcn.Maven</groupId>

<artifactId>Parent</artifactId>

<version>0.0.1-SNAPSHOT</version>

<relativePath>../Parent/pom.xml</relativePath>

</parent>

此时如果子工程的 groupId 和 version 如果和父工程重复则可以删除。

3、在父工程中管理依赖

将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

</dependencyManagement>

4、在子项目中重新指定需要的依赖，删除范围和版本号

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

（三） Maven项目的聚合

为什么要使用聚合？

将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需要逐个手动进行 clean 操作。而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作。

如何配置聚合？

在总的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可

五：Maven在idea工具中的应用

（一）配置tomcat访问

1、点击右上角下拉框，选择Edit Configurations，编辑配置

2、添加tomcat的配置

3、配置tocat服务器，命名，选择tomcat版本，等想配置的信息；最关键的是需要将项目部署出去，可以直接击fix

4、选择war explored，他们的区别

5、当然也可以手动选择要部署出去的项目，特别是有多个项目的情况

6、配置项目结构，特别是要注意依赖的包需要部署到WEB-INF的lib目录下

7、完成后可以启服务器，效果如下

8、war和war exploded的区别

(1) war模式这种可以称之为是发布模式，看名字也知道，这是先打成war包，再发布；

(2) war exploded模式是直接把文件夹、jsp页面、classes等等移到Tomcat 部署文件夹里面，进行加载部署。因此这种方式支持热部署，一般在开发的时候也是用这种方式。

(3) 在平时开发的时候，使用热部署的话，应该对Tomcat进行相应的设置，这样的话修改的jsp界面什么的东西才可以及时的显示出来。

（三）标准的项目结构

Maven有一个很重要的功能是规范项目，标准的项目结构如下所示：

但是你会发现默认创建的项并非是完整的，如写源代码的目录没有，添加方法如下

当前项目结构如下：

1、添加相应的目录，选择打开项目结构

2、项目结构如下

蓝色：源代码绿色：测试

文件（配置信息）

测试资源文件

被排除的(打包里被忽视)

3、目标位置右键添加目录

4、添加后的目录结构如下

附加：

Tomcat插件配置在eclipse和idea中

<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<port>8081</port>
<path>/mmkk</path>
</configuration>
</plugin>