maven中dependency标签介绍

groupId,artfactId,version,type,classifier,scope,systemPath,exclusions,optional 是 maven的9种依赖属性,

其中groupId,artfactId,version是三个基本的依赖坐标,不可缺少。

groupId------包名(一般为域名的反写)。

artfactId------项目名。

version-------版本。

----------------------------------------------------------------------------------

type----------依赖的类型,jar或者war(默认为jar,表示依赖的是一个jar包),另外当type表示为<type>pom.lastUpdated</type> 这种属性时,表示只将jar的描述信息加载了进来,实际的jar包并未导入。

classifier----通常是用于从同一POM构建的拥有不同内容的构件,可选属性,可以是任意的字符串。对附加了classifier属性的包,如果不加上classifier,maven是找不到这个包的,比如下面这个依赖:

<dependency>  
     <groupId>net.sf.json-lib</groupId>   
     <artifactId>json-lib</artifactId>   
     <version>2.2.2</version>  
</dependency> 

然后再去中央仓库查看

发现中央仓库中并没有json-lib-2.2.2.jar这个包 ,自然也就找不到了,有的只是不同版本的json-lib-2.2.2.jar,这个时候classifier就可以指明所想要版本。

<dependency>  
     <groupId>net.sf.json-lib</groupId>   
     <artifactId>json-lib</artifactId>   
     <version>2.2.2</version>
     <classifier>jdk15</classifier>
</dependency>  

这样就可以找到json-lib-2.2.2-jdk15.jar这个包

classifier不仅可以指明版本号,可以指明同一项目的不同组成部分,比如:源文件,javadoc,类文件等。在上面的图中你会发现还有一些json-lib-2.2.2-jdk15-javadoc.jar包和json-lib-2.2.2-jdk15-source.jar包,如果你需要的是javadoc,在XML文档中就可以这样写:

<dependency>  
     <groupId>net.sf.json-lib</groupId>   
     <artifactId>json-lib</artifactId>   
     <version>2.2.2</version>
     <classifier>jdk15-javadoc</classifier>
</dependency>  

同理,如果你需要的时候source包就可以把classifier写成  jdk15-source 。

scope-----依赖作用的范围,指通过POM加载进来的包,作用的范围,范围一共有:编译时,运行时,测试时,

scope一共有compile,runtime,test,system,provided 5种属性值,compile为其默认值,其中:

compile表示在所有范围此jar都生效,

test表示只在测试范围此jar生效,例如Junit(默认compile,不会报错,扩展了test),

runtime表示在测试和运行时此jar生效,例如JDBC驱动(默认compile,不会报错,扩展了runtime),我们在编译时是没有用到这个包的,只在测试和运行时会使用到,

provided表示在编译和测试时此jar生效,例如servlet-api,jsp-api,这个的provided必须填写,不能使用compile,原因是:

我们在eclispe里创建web项目时,eclipse为我们添加了这两个jar包,离开了eclispe之后,到Tomcat中Tomcat又会为我们提供这两个包,所以一直不会报错,但是在我们创建maven项目时,我们就不是web项目了,所以eclispe不会为我们添加这两个jar包,就需要我们通过maven来添加,但是如果设置了compile,在Tomcat中运行时,就会与Tomcat中提供的这两个包产生冲突,所以要设置为provided,

system表示我们手动添加的包,不属于maven仓库,属于别的类库的jar包,只在编译和测试期生效,运行时无效,一般不用,使用时,需要配合下面的systemPath使用。

systemPath--为并非依赖maven的包指明路径。

在项目中创建一个lib作为手动导入的jar包存储位置,

然后再pom.xml文件中添加依赖,

basedir表示根目录。

exclusions---排除传递依赖,解决jar冲突问题,

依赖传递的意思是项目A依赖项目B,项目B依赖项目C,在使用项目A时,就会加载项目B,这样传递依赖就会把项目C,D,E等等加载进来。其中B是A的直接依赖,C是A的间接依赖

例如:A项目依赖B(版本为1.1),C项目也依赖B(版本为1.2),假如现在有一个项目同时依赖项目A和项目B,那么他就会导入两个版本的B,由于B的两个版本不同,这里就会导致冲突,这个时候就需要exclusions来解决冲突,不过maven也有一个机制会避免两个都加载进去,

下面先介绍maven的依赖调节原则:

1,第一原则:路径近者优先原则

                       A→B→C→X(1.1)

                       D→E→X(1.2)

                       使用X(1.2),因为其路径更近

2,第二原则:第一声明者优先原则

                       A→B→X(1.1)

                       C→D→X(1.2)

                      使用X(1.1),因为其先声明

maven会先根据第一原则判断,若路径相等,再根据第二原则判断

但是我们还是使用exclusions来配置更加合理,我们使用spring bean 和 struts2 spring plugin来举个例子说明这个问题并使用exclusions来解决这个问题(spring bean 和 struts2 spring plugin都依赖spring-core但是版本不一样)

先把两个jar包在本地仓库中找到

首先我们还是看看maven自己的解决方案:

由于是先将spring-beans导入所以使用的是spring-core(3.2)

由于是先将struts2-spring-plugin导入所以使用的是spring-core(3.0.5)

上面是路径相同的,接下来的是路径不同的,我建立了一个A项目和B项目,其中A项目中有jsoup-1.11.2,B项目是jsoup-1.11.1,

由于1.11.2版本的是A→jsoup-1.11.2.jar ,1.11.1版本的是A→B→jsoup.1.11.1.jar,所以最后采用jsoup-1.11.2.jar版本。

下面使用exclusions来解决问题:

这是未使用过exclusions过的xml文件当中的内容

下面即使struts2-spring-plugin先导入,也要使用spring-core(3.2),所以需要右键点击struts2-spring-plugin,然后解除依赖

然后会发现

他将两个依赖都解除了,这里手动将第二个的解除依赖删掉就可以

最后使用的是3.2版本的spring-core

optional-----标记依赖是否可传递,默认值false,比如上面的项目A和项目B,

现在查看A

我现在在项目B中标注jsoup为true

再去A中查看

发现B中没有jsoup了

optional可以用来减少项目之间jar包的冲突。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值