您的位置：首页 > 其它

Maven学习笔记之Maven坐标依赖

2016-04-22 00:18 369 查看

Maven学习笔记之Maven坐标依赖

何为maven坐标？

Maven坐标：世界上任何一个构件都可以用maven坐标唯一标识，maven的坐标元素包括：groupId,
artifactId, version, packaging, classifier

maven坐标详解

1) groupId：定义当前maven项目隶属的实际项目，通常与域名反向一一对应；
2) artifactId：定义实际项目中的一个maven项目（模块），推荐使用实际项目作为前缀
3) version：定义maven项目当前所处版本（参见maven版本规范）；
4) packaging：maven项目的打包方式，如jar、war，通常与生成的文件扩展名一致，并且会影响到maven项目构建的生命周期；
5) classifier：帮助定义输出的一些附属构件，如：spring-core-4.1.5.relase-sources.jar，此处，sources代表是一个源码包，常见的还有javadoc。生成附属构件时需要一些插件的帮助。

maven依赖的配置

在pom.xml的根元素project下的dependencies可以包含多个dependency元素，通过dependency声明项目的依赖，每个依赖（dependency）包含的元素有：
1) groupId, artifactId, version：依赖的基本坐标；
2) type：依赖的类型，对应项目定义的packaging，默认值为jar；
3) scope：依赖的范围；
4) optional：标记依赖是否可选（一般不建议使用），比如一个项目即提供了oracle的实现，又提供了mysql的实现，而用户在使用的时候只能选择oracle或者mysql中的一个，此时，对于ojdbc的依赖和mysql-connector-bin的依赖就属于可选依赖；
5) exclusions：排除传递性依赖。

依赖的范围（scope）

1) compile：编译依赖范围，scope默认值；编译、测试、运行的时候都会使用此依赖
2) test：测试的依赖范围，maven测试的时候需要此依赖；
3) provided：已提供依赖范围，编译、测试有效，运行时不在引入此依赖，典型的例子是servlet-api，运行项目的时候tomcat等容器已提供；
4) runtime：运行时依赖范围，运行和测试的时候需要，在编译的时候并不需要，典型的例子：jdbc的驱动实现
5) system：系统的依赖范围，与provider的依赖范围一致，区别是必须通过systemPath制定本地包的路径，此依赖不会通过maven仓库解析，如：
<dependency>
 <groupId>com.alleyz.demo</groupId>
 <artifactId>demo-http</artifactId>
 <version>1.0</version>
 <scope>system</scope>
 <systemPath>${project.basedir}/src/lib/jave-1.2.jar&l
4000
t;/systemPath>
 <systemPath>${project.basedir}/src/lib/jave-1.2.jar</systemPath>
</dependency>

6）import：导入依赖范围。

传递性依赖

以一个使用了Spring的项目demo举个例子：
Demo项目依赖于spring-core，而spring-core项目有依赖于commons-logging，此时，就形成了传递性依赖，demo对于对于spring-core是第一直接依赖，spring-core对于commons-logging是第二直接依赖，demo对于commons-logging是传递性依赖，第一直接依赖范围和第二直接依赖范围决定了传递性依赖的范围，如图：

	第二直接依赖范围
	compile	test	provided	runtime
第一直接依赖范围	compile	compile			runtime
test	test			test
provided	provider		provided	provided
runtime	runtime			runtime

依赖调节

第一原则：路径最近者优先；
第二原则：第一声明者优先。

根据maven的传递性依赖机制，大部分情况下我们只需要关注项目的直接依赖。但是项目中出现依赖问题时，我们得知道maven传递性依赖选择的到底是哪个，下面例子：

项目A存在依赖关系：
1) A依赖B，B依赖C，C依赖X的1.0版本;
2) A依赖D，D依赖X的2.0版本，D依赖M的1.0版本；
3) A依赖E，E依赖于M的2.0版本；

此时，X作为项目A的传递依赖，根据依赖调节的第一原则，引入X的2.0版本；M作为项目A的传递依赖，引入的版本根据D和E的声明先后顺序决定（pom.xml文件中的先后顺序）。

归类依赖

对于同产品的不同依赖进行归类，保证其版本的一致性，一般使用maven属性进行归类依赖，如：
<properties>
 <spring>4.2.5.RELEASE</spring>
</properties>

<dependencies>
 <dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-core</artifactId>
 <version>${spring}</version>
 </dependency>
 <dependency>
 <groupId>org.springframework</groupId>
 <artifactId>spring-context</artifactId>
 <version>${spring}</version>
 </dependency>
</dependencies>

优化依赖

优化规律：
显示声明项目中直接用到的依赖
分析办法：
运行 mvn dependency:analyze
查看Used undeclared dependencies下如果有依赖（直接依赖），则应该将此依赖在pom中声明，
查看Used declared dependencies下如果有依赖（显式声明但未在主代码中用到），则应该在确定无其他直接依赖使用此依赖时删除。

参考资料：《maven实战》

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签： maven maven依赖 maven学习

相关文章推荐

新的分享

章节导航