(二)Maven之坐标和依赖
目录
坐标
引言: 坐标是依赖管理的基础,是构建的唯一标识。
组成元素: 使用groupId、artifactId、version、packaging、classifier标签即可定义一组坐标
规定:groupId,artifactId,version是必须定义的,
packaging的定义是可选的,classifier是不能直接定义的,而是以后附加的插件帮助生成的。
<groupId> org.sonatype.nexus </groupId>
<artifactId> nexus-indexer </artifactId>
<version> 2.0.0 </version>
<packaging> jar </packaging>
groupId: 定义了Maven项目隶属的实际项目。
groupId命名误区:
- Maven项目不一定和实际项目一一对应。实际项目可能被划分为多个Maven项目
- 不应该定义到项目隶属的组织或公司级别,因为组织或公司可能有多个项目。
- 与java包名命名方式相似,通常以域名反向对应。
artifactId: 定义了下实际项目的一个Maven项目
- 建议使用实际项目名作为artifactId的前缀。
- 一般来说,项目中Java类的包都应该基于项目的groupId和artifactId.
version: 定义了Maven项目当前所处的版本。
packaging: 定义了Maven项目的打包方式。
打包方式通常与所生成构件扩展名对应,但是不是绝对的,而且打包方式会影响构建的生命周期。
classifier: 定义了构建输出的一些附属构件。如:在包中生成的文档或源代码。
依赖
eg:
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.1.0.Final</version>
<scope>provided</version>
<optional>true</optional>
<exclusions>
<exclusion>
<groupId>XXXX</groupId>
<artifactId>XXX</artifactId>
</exclusion>
</dependency>
每个依赖包含的元素有:
- groupId,artifactId,version: 依赖的基本坐标
- type: 依赖的类型,对应定义坐标时的packaging,默认值为jar.
- scope: 依赖的范围
- optional: 当前依赖是否可选
- exclusions: 用来排除传递性依赖
依赖范围【scope】
Maven有三种classpath,分别供编译时(编译项目主代码)、测试时(编译和执行测试代码)、运行时(项目实际运行时)使用。
依赖范围: 用来控制依赖同三种classpath的关系,即:是否将依赖引入相应的classpath中。
依赖范围(scope) | 编译classpath 生效 | 测试classpath 生效 | 运行时classpath生效 | 栗子 |
---|---|---|---|---|
compile | Y | Y | Y | spring-core |
test | N | Y | N | JUit |
provided | Y | Y | Y | N |
runtime | N | Y | Y | JDBC驱动实现 |
sytem | Y | Y | N | 除本地的Maven仓库外的jar包 |
- 依赖范围不仅可以控制依赖和classpath的关系,还对传递性依赖产生影响
- 可选依赖不能被传递!!!
扩展: 为什么要使用可选依赖属性(optional)呢?
eg: 项目B进入了X、Y的两个可选依赖,一般由业务形态决定的,业务上存在互斥性,用户不可能同时使用X、Y的功能。
理想情况,其实是不应该使用可选依赖的,本着“单一职责”设计原则,最好分离开来设计。
传递性依赖
compile | test | provided | runtime | |
---|---|---|---|---|
compile | compile | 不传递 | 不传递 | runtime |
test | test | 不传递 | 不传递 | test |
provided | provied | 不传递 | provied | provided |
runtime | runtime | 不传递 | 不传递 | runtime |
注: 左边第一列是第一直接依赖,最上边一行是第二直接依赖。
依赖调解
当产生重复依赖冲突时,采用以下原则解决:
第一原则: 依赖路径最近者优先
eg: 路径1: A -> B -> C -> X(version:1.0)
路径2: A -> D -> X(version:2.0)
因此原则,传递性依赖X(version:2.0)将会被项目引用。第二原则: 路径长度相同,将由pom.xml总依赖声明的顺序决定。
eg: 路径1: A -> B -> Y(version:1.0)
路径2: A -> C -> Y(version:2.0)
若C的引入顺序在B的前面,则 传递性依赖Y(version:2.0)将会被项目引用。
最佳实践
- 排除依赖: 使用exclusion标签定义。
- 归类依赖: 运用Maven属性,使用properties元素定义Maven属性,并引用即可。
- 优化依赖:
mvn dependency:list (以列表方式展示项目依赖列表,包含传递性依赖)
mvn dependency:tree (以树形结构展示项目依赖列表)
最新文章
- Java基础知识笔记(八:集合类)
- 在javascript中使用Json
- BZOJ 3931: [CQOI2015]网络吞吐量
- Sharepoint学习笔记—习题系列--70-576习题解析 -(Q59-Q62)
- 【linux】linux下yum安装后Apache、php、mysql默认安装路径
- Linux下使用yum安装MariaDB
- 第42讲:Scala中泛型类、泛型函数、泛型在Spark中的广泛应用
- (转)Eclipse New Server 【无法输入server name】
- Stanford parser学习:LexicalizedParser类分析
- 横向浅谈移动技术------( 原生,混合,web --- 谁能问鼎移动开发的明天)
- iOS 获取项目名称及版本号
- 有几数组表单,js怎么获得数组并动态相加输出到文本框
- APPCAN学习笔记001---app高速开发AppCan.cn平台概述
- Android开发之如何保证Service不被杀掉(broadcast+system/app)
- JAVA课设 学生基本信息管理 团队博客
- JavaScript 数组基本操作
- 如何让a标签的下划线去掉?
- 解决service层无法注入
- C语言第五次作业函数
- Ubuntu 划词翻译