前面讲了maven一些关于Maven的简单知识,今天我给大家分享一些Maven的依赖管理。我相信用过maven的人都知道,它很重要的功能就是通过依赖来添加jar包。
让我们领略一下Maven是怎么管理我们的jar包的。
一、Maven坐标
1.1、数学中的坐标
在平面上,使用 X 、Y 两个向量可以唯一的定位平面中的任何一个点
在空间中,使用 X、Y、Z 三个向量可以唯一的定位空间中的任意一个点
1.2、Maven 中的坐标
俗称 gav:使用下面三个向量子仓库中唯一定位一个 Maven 工程
在项目中的 pom.xml 文件中,我们可以看到下面gav的定义:
1)groupid:公司或组织域名倒序
<groupid>com.zyh.maven</groupid>
2)artifactid:模块名,也是实际项目的名称
<artifactid>Maven_ch01</artifactid>
3)version:当前项目的版本
<version>0.0.1-SNAPSHOT</version>
1.3、Maven 坐标和仓库,jar 包的关系
仓库是Maven 用来存放 jar 包的地方。
那么依照上面定义的 gav,我们执行 mvn -install 命令,会出现什么情况呢?
首先进入到我们 Maven 的安装配置 ,通过 settings.xml 文件配置的仓库目录。
将我们上面配置的 gav 向量组合起来就是目录:
com\zyh\maven\Maven-ch01\1.0-SNAPSHOT
其次,我们观察打出来的 jar 包:
Maven-ch01-1.0-SNAPSHOT.jar
也就是 artifactid-version.jar
二、依赖
什么是 依赖?相信有过一定开发经验的人知道,每当我们需要使用某个框架时,比如 SpringMVC,那么我们需要导入相应的 jar 包,但是手动导入包的时候,往往会漏掉几个 jar 包,
那么在使用该框架的时候系统就会报错。那么我们就说导入的包与未导入的包存在依赖关系。而使用 Maven,我们只需要在 pom.xml 文件中进行相应的配置,它就会帮助我们自动管理 jar 包之间的依赖关系。
2.1、依赖的详细配置
为了避免不知道说的哪些配置属性,看下面图就明白了,就是dependency下的属性配置,全部有9个,讲其中的7个。
以 Junit 为例,在 pom.xml 文件中进行详细而完整的配置
<project> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <type>...</type> <scope>...</scope> <optional>...</optional> <exclusions> <exclusion> <groupId>...</groupId> <artifactId>...</artifactId> </exclusion> </exclusions> </dependency> </dependencies> </project>
1)groupId、artifactId、version是依赖的基本坐标,缺一不可,这三个可以不用将,都知道,重要的是除了这三个之外的配置属性需要我们理解
2)type:依赖的类型,比如是jar包还是war包等
默认为jar,表示依赖的jar包
注意:<type>pom.lastUpdated</type> 这个我们在上面添加servlet-jar的时候就遇到过,看到lastUpdated的意思是表示使用更新描述信息,占位符作用,通俗点讲,选择该类型,
jar包不会被加载进来,只是将该jar包的一些描述信息加载进来,使别的jar包在引用他时,能够看到一些相关的提示信息,仅此而已,所以说他是个占位符,只要记住他的jar包不会被加载进来。
3)optional:标记依赖是否可选。默认值false
比如struts2中内置了log4j这个记录日志的功能,就是将log4j内嵌入struts2的jar包中,而struts2有没有log4j这个东西都没关系,有它,提示的信息更多,没它,也能够运行,
只是提示的信息就相对而言少一些,所以这个时候,就可以对它进行可选操作,想要它就要,不想要,就设置为false。
4)exclusions:排除传递依赖,解决jar冲突问题
依赖传递的意思就是,A项目 依赖 B项目,B项目 依赖 C项目,当使用A项目时,就会把B也给加载进来,这是传递依赖,依次类推,C也会因此给加载进来。
这个有依赖传递有好处,也有坏处,坏处就是jar包的冲突问题,比如,A 依赖 B(B的版本为1),C 依赖 B(B的版本为2),如果一个项目同时需要A和C,那么A,C都会传递依赖将B给加载进来,
问题就在这里,两个B的版本不一样,将两个都加载进去就会引起冲突,这时候就需要使用exclusions这个属性配置了。maven也会有一个机制避免两个都加载进去,
maven 默认配置在前面的优先使用,但是我们还是需要使用exclusions来配置更合理,这里使用spring bean 和 struts2 spring plugin 来举例子说明这个问题并使用exclusions解决这个问题。
(spring bean 和 struts2 spring plugin都需要依赖spring-core,但版本不一样)
从本地仓库中找到这两个jar包
maven自己的解决方案如下:
maven 默认配置在前面的优先使用,下面是证明
先将spring-beans加载进去的,所以会将spring-beans依赖的spring-core的版本加载进来。
先将struts2-spring-plugin加载进来,那么就会将其依赖的spring-core的版本加载进来
使用exclusions来配置
即使struts2-spring-plugin 配置在前面,也需要使用3.2.0版本。则需要为struts2-spring-plugin 排除依赖(不使用3.0.5依赖)
注意:这样,就将struts2-spring-plugin依赖的spring-core的版本排除依赖了,也就是该依赖的spring-core不会在加载进来,查看代码,看是否符合要求,如果不符合要求,需要手动的修改
2.2、依赖的范围scope
scope:依赖范围,意思就是通过pom.xml加载进来的jar包,来什么范围内使用生效,范围包括编译时,运行时,测试时
一般情况下,我们对前面三个依赖用的比较多。下面的主程序表示maven 目录结构 src/main/java.测试程序目录结构为:src/test/java
1)compile 范围依赖
对主程序是否有效:有效
对测试程序是否有效:有效
是否参与打包:参与
是否参与部署:参与
典型例子:log4j
默认值,如果选择此值,表示编译、测试和运行都使用当前jar
2)test 范围依赖
对主程序是否有效:无效
对测试程序是否有效:有效
是否参与打包:不参与
是否参与部署:不参与
典型例子:Junit
表示只在测试时当前jar生效,在别的范围内就不能使用该jar包。例如:junit 。此处不写也不报错,因为默认是compile,compile包扩了测试
3)provided 范围依赖
对主程序是否有效:有效
对测试程序是否有效:有效
是否参与打包:不参与
是否参与部署:不参与
典型例子:servlet-api.jar,一般在发布到 服务器中,比如 tomcat,服务器会自带 servlet-api.jar 包,所以provided 范围依赖只在编译测试有效。
表示编译和测试时使用当前jar,运行时不在使用该jar了。例如:servlet-api、jsp-api等。
分析:
什么意思呢? 在我们以前创建web工程,编写servlet或者jsp时,就没导入过jar包把,因为myeclipse或者别的ide帮我们提供了这两个jar包,内置了,
所以我们在编译期测试期使用servlet都不会报缺少jar包的错误,而在运行时期,离开了myeclipse或别的ide,就相当于缺失了这两个jar包,但此时tomcat又
会帮我们提供这两个jar,以便我们不会报错,所以,这两个很特殊。看图
1)开发阶段(MyEclipse提供),看下图以此证明我们说的
java web 5.0项目:
java web 6.0项目:
2)运行阶段(tomcat提供)
所以,根据这个特点,如果使用maven开发项目,就不是web项目了,那么myeclipse就不会在给我们提供这两个jar包,我们就必须自己手动通过坐标从仓库中获取,
但是针对上面的分析,当运行的时候,tomcat会帮我们提供这两个jar包,所以我们自己从仓库中获取的jar包就不能和tomcat中的冲突,
那么就正好可以通过provided这个属性,来设置这两个jar的作用范围,就是在变异时期和测试时期生效即可。这个例子就可以解释上面创建maven web时产生的错误和解决方案了。
4)runtime 范围依赖
在测试、运行的时候依赖,在编译的时候不依赖。例如:JDBC驱动,项目代码只需要jdk提供的jdbc接口,只有在执行测试和运行项目的时候才需要实现jdbc的功能。
表示测试和运行时使用当前jar,编译时不用该jar包。例如:JDBC驱动。JDBC驱动,在编译时(也就是我们写代码的时候都是采用接口编程,压根就没使用到JDBC驱动包内任何东西,
只有在运行时才用的到,所以这个是典型的使用runtime这个值的例子),此处不写也不报错,理由同上。
5)表示我们自己手动加入的jar包,不属于maven仓库(本地,第三方等),属于别得类库的这样的jar包,只在编译和测试期生效,运行时无效。一般不用
四、依赖传递
比如我们创建三个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;
五、调节原则
这个就是maven解决传递依赖时jar包冲突问题的方法,按照两种原则,上面已经介绍了一种了,就是下面的第二原则
1)第一原则:路径近者优先原则
A-->B-->C-->D-->X(1.6)
E-->D-->X(2.0)
使用X(2.0),因为其路径更近
2)第二原则:第一声明者优先原则。就是如果路径相同,maven 默认配置在前面的优先使用
A-->B --> X(1.6)
C-->D--> X(2.0)
这样就是路径相同,那么如果A在前面,C在后面,则使用X(1.6)
maven会先根据第一原则进行选择,第一原则不成,则按第二原则处理。
好就点“推荐”哦!