Maven 之 依赖管理
来源:互联网 发布:朱佑樘和张皇后知乎 编辑:程序博客网 时间:2024/06/05 10:24
最简单的依赖
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>cn.huang.test</groupId> <artifactId>mavenTest</artifactId> <packaging>pom</packaging> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.4</version> <!--不声明依赖范围scope,默认是compile--> <scope>test</scope> </dependency> </dependencies></project>
在Maven中需要使用在dependencies中定义一个或者多个dependency元素,来声明项目的一个或者多个依赖。 每个依赖元素dependency包括:
groupId 依赖的坐标
artifactId 依赖的坐标
version 依赖的坐标
scope 依赖范围
exclusions 用来排除传递性依赖
type 依赖的类型,对应项目坐标定义的packaging,默认为jar
classifier 用来帮助定义构件输出的一些附属构件
systemPath 表示该依赖项在当前系统的绝对路径
依赖是使用Maven坐标来定位的,而Maven坐标主要由GAV(groupId, artifactId, version)构成。因此,使用任何一个依赖之间,你都需要知道它的Maven坐标。
依赖范围(scope )
compile(默认):编译范围的依赖,它在编译和打包的时候都会把该依赖打包进去
provided:在编译和测试范围有效,最后生成war包时不会打包进去。
runtime:运行时依赖,编译的时候不依赖。
system:系统依赖范围
import:导入依赖范围
依赖范围 与 classpath的关系
例一:对于Junit,一般来说你只有在运行测试的时候需要它,也就是说,它对于src/main/java的classpath没什么意义,并且,将Junit的jar文件打入最终的发布包也不是好事,这无谓的增加了发布包的大小。 其实我们应该这样做:
<dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.4</version> <scope>test</test></dependency>
于是,junit对于主源码classpath不可用,对于测试源码classpath可用,不会被打包。
例二:在开发javaee应用的时候我们一定会用到servlet-api,它对于主源码和测试源码都是必要的,因为我们的代码中会引入servlet-api的包。但是,在打包的时候,将其放入WAR包就会有问题,因为web容器会提供servlet-api,如果我们再将其打包就会造成依赖冲突,解决方案如下:
<dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.4</version> <scope>provided</scope></dependency>
将依赖范围设置成provided,就意味着该依赖对于主源码classpath,以及测试classpath可用,但不会被打包。这正是servlet-api所需要的。
分类器(classifer)
GAV是Maven坐标最基本最重要的组成部分,但GAV不是全部。还有一个元素叫做分类器(classifier),90%的情况你不会用到它,但有些时候,分类器非常不可或缺。 举个简单的例子,当我们需要依赖TestNG的时候,简单的声明GAV会出错,因为TestNG强制需要你提供分类器,以区别jdk14和jdk15,我们需要这样声明对TestNG的依赖:
<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>5.7</version> <classifier>jdk15</classifier></dependency>
你会注意到maven下载了一个名为testng-5.7-jdk15.jar的文件。其命名模式实际上是--.。
理解了这个模式以后,你就会发现很多文件其实都是默认构件的分类器扩展,如 myapp-1.0-test.jar, myapp-1.0-sources.jar。
分类器还有一个非常有用的用途是:我们可以用它来声明对test构件的依赖,比如,我们在一个核心模块的src/test/java中声明了一些基础类,然后我们发现这些测试基础类对于很多其它模块的测试类都有用。没有分类器,我们是没有办法去依赖src/test/java中的内容的,因为这些内容不会被打包到主构件中,它们单独的被打包成一个模式为--test.jar的文件。 我们可以使用分类器来依赖这样的test构件:
<dependency> <groupId>org.myorg.myapp</groupId> <artifactId>core</artifactId> <version>${project.version}</version> <classifier>test</classifier></dependency>
依赖传递性的冲突问题
参考文章:http://www.cnblogs.com/meet/p/6417496.html
依赖传递性冲突问题解决办法总结
1、通过调整dependency的顺序来解决:哪个依赖的顺序在前面就依赖哪个
2、自己添加一个dependeny来解决:因为该路径是最小的。
3、通过exclusions元素排除不想要的传递性依赖
依赖管理(dependencyManagement)
实际的项目中,会有一大把的Maven模块,而且你往往发现这些模块有很多依赖是完全相同的,A模块有个对spring的依赖,B模块也有,它们的依赖配置一模一样,同样的groupId, artifactId, version,或者还有exclusions, classifer。细心的分会发现这是一种重复,重复就意味着潜在的问题,Maven提供的dependencyManagement就是用来消除这种重复的。
正确的做法是:
1. 在父模块中使用dependencyManagement配置依赖
2. 在子模块中使用dependencies添加依赖
dependencyManagement实际上不会真正引入任何依赖,dependencies才会。但是,当父模块中配置了某个依赖之后,子模块只需使用简单groupId和artifactId就能自动继承相应的父模块依赖配置。 这里是一个来自于《Maven权威指南》的例子: 父模块中如此声明:
<project> <modelVersion>4.0.0</modelVersion> <groupId>org.sonatype.mavenbook</groupId> <artifactId>a-parent</artifactId> <version>1.0.0</version> ... <dependencyManagement> <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.2</version> </dependency> ... <dependencies> </dependencyManagement>
子模块中如此声明:
<project> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.sonatype.mavenbook</groupId> <artifactId>a-parent</artifactId> <version>1.0.0</version> </parent> <artifactId>project-a</artifactId> ... <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> </dependencies></project>
项目实战中导入依赖的一些原则
例如有一下工程,使用taotao-manage聚合将所有的子工程
子工程之间的依赖关系
taotao-manage-web -> taotao-manage-service -> taotao-manage-mapper -> taotao-manage-pojo
导入依赖的原则:
1、所有工程都需要的依赖应该在聚合工程(taotao-manage)中导入。
比如:
2、在使用依赖的最底层导入。
比如,mybatis的依赖不需要在 taotao-manage-pojo中导入,只需要在taotao-manage-mapper中导入:
3、运行时所需要的依赖在web工程中导入。
比如,以下依赖只需要在taotao-manage-web的pom文件中导入:
- Maven之依赖管理
- Maven 之 依赖管理
- Maven讲解之 依赖管理
- maven项目管理之-07-依赖传递
- maven项目管理之-08-依赖冲突
- maven依赖管理
- maven 项目依赖管理
- Maven的依赖管理
- maven 项目依赖管理
- Maven 依赖管理
- maven依赖管理
- maven 管理依赖
- Maven依赖管理
- maven 依赖管理
- Maven的依赖管理
- Maven管理依赖
- maven--依赖管理
- Maven 依赖管理
- 将javaWeb项目部署到服务器 1. **工具:XshellPortable** **操作步骤:** **1. 登陆到服务器** 1. 运行shellPortable工具
- pymongo连接mongodb3.4.7
- com.mysql.jdbc.exceptions.jdbc4.CommunicationsException
- Docker学习笔记(3)
- 初探nodeJS
- Maven 之 依赖管理
- CocoaPods详解之----使用篇
- linux : macro for syslog
- 导出pdf之--下载到本地
- linkedlist比ArrayList优点
- Python 中的range,以及numpy包中的arange函数
- com.android.support冲突的解决办法
- unity中调用android的剪切板
- Hibernate5.* 环境配置及远程连接数据库,CRUD操作