Maven-依赖管理

一. 依赖管理

1. maven-依赖管理-依赖配置

• 依赖：指当前项目运行所需要的jar包。一个项目中可以引入多个依赖：
• 例如：在当前工程中，我们需要用到logback来记录日志，此时就可以在maven工程的pom.xml文件中，引入logback的依赖。具体步骤如下：

1.  在pom.xml中编写标签
2.  在标签中使用 引入坐标
3.  定义坐标的 groupId、artifactId、version
4.  点击刷新按钮，引入最新加入的坐标

 

    
    
        
            ch.qos.logback
            logback-classic
            1.2.3
        
    

注意事项：

1. 如果引入的依赖，在本地仓库中不存在，将会连接远程仓库 / 中央仓库，然后下载依赖

  （这个过程会比较耗时，耐心等待）

2. 如果不知道依赖的坐标信息，可以到 mvn 的中央仓库（ https://mvnrepository.com/ ）中      搜索

 添加依赖的几种方式：

1. 利用中央仓库搜索的依赖坐标

 2. 利用IDEA工具搜索依赖

 3. 熟练上手maven后，快速导入依赖

 2. maven-依赖管理-依赖传递

2.1 依赖具有传递性

• 早期我们没有使用maven时，向项目中添加依赖的jar包，需要把所有的jar包都复制到项目工程下。如下图所示，需要logback-classic时，由于logback-classic又依赖了logback-core和slf4j，所以必须把这3个jar包全部复制到项目工程下：

我们现在使用了 maven ，当项目中需要使用 logback-classic 时，只需要在 pom.xml 配置文件中，添

加 logback-classic 的依赖坐标即可。

• 在pom.xml文件中只添加了logback-classic依赖，但由于maven的依赖具有传递性，所以会自动把所依赖的其他jar包也一起导入。

依赖传递可以分为：

1. 直接依赖：在当前项目中通过依赖配置建立的依赖关系

2. 间接依赖：被依赖的资源如果依赖其他资源，当前项目间接依赖其他资源

 比如以上图中：

• projectA依赖了projectB。对于projectA 来说，projectB 就是直接依赖。
• 而projectB依赖了projectC及其他jar包。 那么此时，在projectA中也会将projectC的依赖传递下来。对于projectA 来说，projectC就是间接依赖。

2.2. 排除依赖

问题：之前我们讲了依赖具有传递性。那么 A 依赖 B ， B 依赖 C ，如果 A 不想将 C 依赖进来，是否可               以做到？

答案：在 maven 项目中，我们可以通过排除依赖来实现。

什么是排除依赖？

• 排除依赖：指主动断开依赖的资源。（被排除的资源无需指定版本）

依赖排除示例：

• maven-projectA依赖了maven-projectB，maven-projectB依赖了Junit。基于依赖的传递性，所以maven-projectA也依赖了Junit

 使用排除依赖后：

 
            com.itheima
            maven-projectB
            1.0-SNAPSHOT
            
            
            
                
                    junit
                    junit
                
            
            
        

3. maven依赖管理-依赖范围

什么是依赖范围以及依赖范围的配置方式

• 我们在pom.xml配置文件当中所配置的依赖，默认情况下是可以在任何地方使用的。
• 在项目中导入依赖的jar包后，默认情况下，可以在任何地方使用。

• 这里所说的任何地方指的是这个jar包可以在main这个文件夹下使用，也就是主程序范围内有效；也可以在test这个文件夹下使用，也就是测试程序范围内有效；也可以在这个项目打包的时候，将这个jar包包含进去，也就是这个依赖会参与这个项目的打包运行，那这是默认情况。
• 如果希望限制依赖的使用范围，可以通过标签设置其作用范围。
• 而在Maven当中，我们是可以通过一个标签叫做scope来控制这个依赖的作用范围。

 作用范围：

1.  主程序范围有效（main文件夹范围内）
2.  测试程序范围有效（test文件夹范围内）
3.  是否参与打包运行（package指令范围内）

• scope配置为默认值compile的时候，它在任何范围内都是有效的，主程序范围内有效，测试程序范围内有效，也会参与打包。
• 我们在进行项目开发时，绝大部分依赖scope的取值都是默认值compile，那如果取的是默认值scope就不用配置了。
• scope标签的第二个取值test，test代表的是这个依赖仅仅在测试程序范围内有效，在主程序当中不能使用，也不会参与项目的打包，那这个比较典型的就是junit单元测试，它仅仅在测试范围内有效。
• scope标签的第三个取值provided，provided代表的是在主程序以及测试程序范围内都有效，但是它不参与项目的打包，那这个比较典型的就是我们后面要提到的一个技术servlet。
• scope标签的第四个取值runtime，runtime代表的是这个依赖，它在主程序当中不能使用，在测试程序当中可以使用，也可以参与项目的打包运行，那这个比较典型的就是后面我们讲解数据库这一块要讲到的jdbc的驱动，通过Java来操作数据库的一个jar包。

在程序当中我们要来验证这个依赖有没有生效，我们主要去看一下，能不能使用里面的接口或者是类就可以了。

那在logback当中，给我们提供了一个接口叫做Logger。

•   如上图所示，给junit依赖通过scope标签指定依赖的作用范围。 那么这个依赖就只能作用在  测 试环境，其他环境下不能使用。

我们可以额外配置一个插件，是一个打包插件，那默认Maven呢它也给我们提供了打包的功能，但是它所提供的这个打包的插件，只能够将当前项目的资源打进去，它所依赖的这些jar包，它是并不会打进去的。在Java中，当前项目的资源指的是当前项目中正在使用的资源，包括类、方法、变量、资源文件等。

4. maven依赖管理-生命周期

4.1 介绍

• Maven的生命周期就是为了对所有的maven项目构建过程进行抽象和统一，就是来描述一次项目构建要经历哪些阶段。
  

• 在 Maven 出现之前，项目构建的生命周期就已经存在，软件开发人员每天都在对项目进行清理，编译， 测试及部署。虽然大家都在不停地做构建工作，但公司和公司间、项目和项目间，往往使用不同的方式做类似的工作。
• Maven 从大量项目和构建工具中学习和反思，然后总结了一套高度完美的，易扩展的项目构建生命周期。这个生命周期包含了项目的清理，初始化，编译，测试，打包，集成测试，验证，部署和站点生成等几乎所有构建步骤。

Maven对项目构建的生命周期划分为3套（相互独立）：

• clean：负责清理工作。主要就是来清理上一次项目构建所产生的一些文件，比如编译之后的              class字节码文件，打包之后的jar包文件。
• default：负责整个项目构建的核心工作。如：编译、测试、打包、安装、部署等。
• site：生成报告、发布站点等(很少会用到)

这三套相互独立的生命周期，每一个生命周期又分为若干个阶段，而这些阶段，是生命周期当中最细化的操作。

每套生命周期包含一些阶段(phase)，在同一套生命周期当中，阶段是有先后顺序的，先运行前面的阶段，再运行后面的阶段，而后面的阶段依赖于前面的阶段的，那也就是说在同一套生命周期当中，我们运行后面的阶段进行项目的构建，前面的阶段它也会运行。

三套生命周期又包含哪些具体的阶段呢 , 我们来看下面这幅图 :

 

我们看到这三套生命周期，里面有很多很多的阶段，这么多生命周期阶段，其实我们常用的并不多，我们使用Maven进行项目构建，其实主要关注其中的五个阶段即可：

• clean：移除上一次构建生成的文件
• compile：编译项目源代码，将项目的源代码编译成class字节码文件
• test：使用合适的单元测试框架运行测试(junit)
• package：将编译后的文件打包，打成jar包或者是war包，如：jar、war等
• install：指的是将打包好的jar包或者是war包安装到Maven的本地仓库

二次提醒：在同一套生命周期中，当运行后面的阶段时，前面的阶段也会运行。

Maven的生命周期以及生命周期的各个阶段都是抽象的概念，这意味着生命周期它本身并不执行任何具体的操作，在Maven的设计中，它的具体操作 / 实际任务(如源代码编译)是由与其绑定的Maven插件来完成的，因为Maven本质就是一个插件执行框架，所有的工作都是由插件完成的。

 IDEA工具为了方便程序员使用maven生命周期，在右侧的maven工具栏中，已给出快速访问通道

在Maven面板当中，最上面的这一块展示的就是生命周期，Plugins展示的是于生命周期各个阶段绑定的插件，当我们双击上面的生命周期的各个阶段在运行的时候，其实最终是由这些插件来完成对应的工作的。

 

•  生命周期的顺序是：clean --> validate --> compile --> test --> package --> verify --> install --   > site  --> deploy

我们需要关注的就是： clean --> compile --> test --> package --> install

 4.2 执行

在日常开发中，当我们要执行指定的生命周期时，有两种执行方式：

1.  在idea工具右侧的maven工具栏中，选择对应的生命周期，双击执行
2.  在DOS命令行中，通过maven命令执行

方式一：在 idea 中执行生命周期

• 选择对应的生命周期，双击执行

 compile：

 test：

package：

 install：

clean：

 方式二：在命令行中执行生命周期

1. 进入到DOS命令行