>> maven坐标由5个元素组成:
* groupId:定义当前maven项目隶属的实际项目
maven项目和实际项目不一定是一对一关系,比如SpringFramework这一实际项目,其对应的maven项目会有很多,比如spring-core、spring-context等。这是由于maven中模块的概念,因此一个实际项目往往会被划分成很多模块。其次,groupId不应该对应项目隶属的组织或公司,因为一个组织下面会有很多项目。最后,groupId表示方式与Java包名表示方式类似,通常与域名反向一一对应。比如org.sonatype.nexus,org.sonatype是公司域名,而nexus表示Nexus这一实际项目,该groupId与nexus.sonatype.org域名对应。
* artifactId:定义实际项目中的一个maven项目(模块),推荐做法是使用实际项目名称作为artifact的前缀,比如nexus-indexer
* version:定义maven项目当前所处的版本
* packaging:定义maven项目打包方式,默认为jar
* classifier:定义构建输出的一些附属构件,附属构件与主构件对应,如nexus-indexer-2.0.0.jar,该项目可能还会通过使用一些插件生成如nexus-indexer-2.0.0-javadoc.jar、nexus-indexer-2.0.0-sources.jar等附属构件,这时候,javadoc和sources就是这两个附属构件的classifier。这样,附属构件也就拥有了自己的唯一坐标。注意classifier是不能直接定义的,它是由附加插件帮助生成的。
注:构件生成的文件名规则为:artifactId-version[-classifier].packing,此外,maven仓库的布局也是基于maven坐标。
>> 依赖的配置:
<dependencies>
<dependency>
<groupId>com.icegreen</groupId>
<artifactId>greenmail</artifactId>
<version>1.3.1b</version>
<type>...</type>
<scope>test</scope>
<optional>...</optional>
<exclusions>
<exclusion>
...
</exclusion>
<exclusion>
...
</exclusion>
</exclusions>
</dependency>
<dependency>
...
</dependency>
</dependencies>
每个依赖可以包含的元素有:
* groupId、artifactId和version:依赖的基本坐标
* type:依赖的类型,对应于项目坐标定义的packaging,大部分情况下都为默认的jar
* scope:依赖的范围
* optional:标记依赖是否可选
* exclusions:排除传递性依赖
>> 依赖范围scope
依赖范围就是用来控制依赖与这三种classpath(编译classpath、测试classpath、运行classpath)的关系,maven有以下几种依赖范围:
* compile:编译范围,如果没有指定,默认就是这个范围,使用此范围的maven依赖,对于编译、测试、运行三种classpath都有效。
* test:测试依赖范围,只对测试classpath有效,在编译主代码或者运行项目的时候无法使用此依赖,典型就是junit
* provided:已提供依赖范围。对于编译和测试有效,但在运行时无效。典型例子就是servlet-api,编译和测试项目时候需要用到该依赖,但在运行项目的时候,由于容易已经提供,就不需要重复的引入了。
* runtime:运行时依赖,对于测试和运行有效。但是编译无效,典型就是JDBC-Driver实现,项目主代码的编译只需要JDK提供的JDBC接口,只有在执行测试或者运行项目的时候才需要实现上述具体的JDBC驱动。
* system:系统范围依赖。该依赖于三种classpath的关系,和provided完全一致。但是,使用system范围的依赖时候必须通过systemPath元素显示指定依赖文件的路径。由于此类依赖不是通过maven仓库解析的,而是往往与本机系统绑定,可能造成构建的不可移植,因此谨慎使用,systemPath可以引用环境变量,如:
<dependency>
<groupId>javax.sql</groupId>
<artifactId>jdbc-stdext</artifactId>
<version>2.0</version>
<scope>system</scope>
<systemPath>${java.home}/lib/rt.jar</systemPath>
</dependency>
* import:导入依赖范围。该依赖不会对三种classpath产生实际影响
图示说明依赖范围与classpath关系:
依赖范围 compile有效 test有效 runtime有效 compile Y Y Y test -- Y -- provided Y Y -- runtime -- Y Y system Y Y --
>> 传递性依赖
依赖范围不仅可以控制依赖与三种classpath的关系,还对传递依赖产生影响。比如:account-email依赖spring-core,而spring-core依赖commons-logging。account-email对于spring-core的依赖范围是compile,spring-core对于commons-logging依赖范围是compile,那么account-email对于commons-logging这一传递依赖范围就是comile。假设A依赖B,B依赖C,我们说A对于B是第一直接依赖,B对于C是第二直接依赖,A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖范围决定了传递依赖的范围。
图示依赖范围影响传递依赖:table首列为第一直接依赖,table首行是第二直接依赖,table数据为传递依赖影响范围
1
2
3
4
5
|
compile test provided runtime
compile compile -- -- runtime
test test -- -- test
provided provided -- provided provided
runtime runtime -- -- runtime
|
>> 依赖调解:
如果A -> B -> C -> X1.0,然后还有一个 A -> D -> X2.0,一个项目依赖X的两个版本,那么应该选哪个呢,maven依赖调解原则:
第一原则:路径最近者优先,比如上面,肯定是X2.0路劲优先
第二原则:如果路径长度一样,那么第一声明者优先,也就是在pom的dependence里面优先声明的优先使用。哦也~~
>> 可选依赖
如果A -> B,而B -> X并且 B-> Y,但是如果X和Y是optional的时候,A不依赖X和Y,也就是X和Y不会被传递。
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>1.0.0</version>
<optional>true</optional>
</dependency>
</dependencies>
当其他项目需要依赖这个jar包的时候,需要自己去显示的声明。但是在理想情况下,是不应该出现这个传递依赖的。
>> 排除依赖
可以使用exclusion排除传递依赖,不解释
>> 归类依赖
在pom中定义版本变量version,统一使用版本变量名,方便升级,不解释
>> 优化依赖
项目中引入各种依赖的时候,可能会有很多依赖相同的jar包但是版本不一致的,但是maven非常智能的通过它的依赖调解最后确保只会引用唯一一个版本。
可以运行命令 :
mvn dependency:list:去查看当前项目已解析的依赖列表
mvn dependency:tree:以树状结构查看依赖树
mvn dependency:analyze:分析项目的依赖问题
本人博客已搬家,新地址为:http://yidao620c.github.io/