硬依赖
指的就是必须由本模块来引入的依赖
传递依赖
当引入其它模块时,由于其它模块中已经有了某些jar包的依赖了,将自动把依赖关系导入到本模块
如,A模块已经配置了对hibernate的依赖,
当B模块中引入A模块的依赖时,hibernate的依赖将自动传入到B模块中。
此时,B模块中不用再配置hibernate的依赖了,会根据传递过来的依赖自动导入那些jar包!
依赖排除
由于有了传递性依赖的特征,当不想导入当前所引入的模块的依赖时,可以使用排除策略,将对应的依赖排除掉。
==================================================================
硬依赖
user-core模块
该模块用于定义实体类,需要的依赖的jar包:hibernate, mysql-connector, log4j, junit
依赖包的说明:
mysql-connector用来使用Java连接Mysql数据库
hibernate用来持久化对象
junit用来做单元测试
log4j用来做日志
依赖包的坐标通过上面的网址进行查询即可
则POM.xml配置如下:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.gc.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>user-core</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.2.6.Final</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.26</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
</dependency>
</dependencies>
</project>
==================================================================
传递依赖
user-dao模块
本模块主要功能是对对象进行持久化操作,当然就离不开hibernate的支持。
由于该模块需要使用到user-core模块中的实体,那么就需要引入user-core模块
那么,user-core模块就需要进行发布(deploy),当发布到私服上,本地就可以下载到该模块的jar包了
注意:
user-core模块中已经依赖了hibernate的jar包,当user-dao模块引入user-core模块时,
user-dao模块就不需要在pom.xml中配置对hibernate的依赖了,因为依赖会传递!
当然,由于user-core模块中对mysql-connector, log4j都有依赖,那么本模块也会自动引入它们!
注意:
依赖传递需要明确的两点:
1.依赖是否传递由scope来决定
2.传递的是依赖关系,而不是将jar包从A模块拷贝到B模块
由于Junit的scope定义为了test,所以该依赖关系不会传递到另一个模块中,
所以,本模块中如果要使用Junit,那么还需要配置对Junit的依赖!
本模块中的pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.gc.user</groupId>
<artifactId>user-dao</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>user-dao</name>
<url>http://maven.apache.org</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<scope>test</scope>
</dependency>
<!-- 引入user-core,将会发生传递性依赖:user-core中的依赖是否会导入到本模块中,还要根据scope决定! --> <dependency>
<groupId>com.gc.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
依赖的scope属性
决定该依赖是否传递,是否被打入war包
scope=compile,默认范围,该范围的依赖传递最强,编译,打包,运行都需要;
scope=test,依赖不会传递,生成war包时不会导入;测试包不需要传递,也不需要打入到war包。
scope=provided,依赖不会传递,生成war包时不会导入。仅编译,测试时有用,与test范围有点类似,但是出发点不一样。如servlet-api,容器已经提供了,就不能再包含了,否则,会导致包冲突等异常发生。
scope=runtime,编译时没有依赖,运行时有依赖
scope=system,导入本地jar包,通过指定本地路径来导入
scope=import
依赖传递的冲突
本模块依赖其它几个模块,而这几个模块中对某个jar包的依赖版本不同,那么本模块将使用哪个依赖呢?
Maven将自动根据"最短路径原则"来确定!
最短路径原则:
如果本地显示依赖了某个jar包,则用本地的;
如果本地没有显示依赖,而是通过依赖传递依赖的某个jar包:
首先根据最短依赖原则确定;
如果路径长度都相同,则根据依赖书写顺序确定;
依赖的排除
Maven基于最短路径原则,解决了依赖冲突的问题,我们还可以通过依赖排除来进一步干涉依赖的传递行为。
如,引入user-core时,我不想使用user-core关于log4j的依赖,那么在引入user-core的时候,声明需要排除的依赖即可:
<!-- 引入user-core,将会发生传递性依赖:user-core中的依赖是否会导入到本模块中,还要根据scope决定! -->
<dependency>
<groupId>com.gc.user</groupId>
<artifactId>user-core</artifactId>
<version>0.0.1-SNAPSHOT</version>
<exclusions>
<!-- 排除user-core模块中关于log4j的依赖 -->
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
依赖的显示声明,精确控制依赖的版本
基于Maven的最短路径原则解决了多个相同依赖冲突的问题
依赖排除又提供了一种依赖冲突的解决方案
此外,我们还可以直接在本模块中声明对某个jar包的依赖,优先级最高,冲突也就自动解决了
分享到:
相关推荐
依赖范围(scope)是Maven依赖管理的一个重要概念。scope定义了依赖项的使用范围,主要有以下几个选项:compile、provided、runtime和test。compile表示依赖项在编译时需要,provided表示依赖项在编译和测试时需要,但...
在Java开发领域,Maven是广泛使用的...综上所述,这个“maven依赖包(用于博客项目)”包含了构建博客应用所需的全部或部分关键库,通过Maven的依赖管理和构建机制,能够有效地组织和管理项目的复杂性,加速开发进程。
5. **版本管理**:Maven遵循严格的版本管理规则,如SNAPSHOT和RELEASE版本的区别,有助于保持项目的稳定性和可控性。 6. **依赖冲突解决**:Maven采用"最接近原则"解决依赖冲突,即当两个或更多依赖引入相同jar的...
Maven的依赖管理遵循一些原则,如“最接近优先”规则,如果一个项目有两个或更多版本的相同依赖,Maven会优先选择离项目最近的依赖。此外,Maven还支持排除依赖,如果你不想引入某个特定的子依赖,可以通过...
**二、Maven依赖原则** Maven的依赖原则主要为了解决多个依赖之间的版本冲突问题,它遵循两个基本规则: 1. **路径最短优先原则**:当两个不同版本的相同依赖出现在依赖树中,Maven会选择路径较短的那个版本。例如...
在Java开发领域,Maven以其规范化的项目构建过程和丰富的依赖管理功能而备受推崇。本文将深入探讨Maven的核心概念、工作原理以及如何配置和使用。 **一、Maven的核心概念** 1. **POM(Project Object Model)**: ...
在现代软件开发过程中,Maven 作为 Java 项目构建管理和依赖管理工具之一,被广泛使用。本篇文章将详细解析如何通过 Maven 构建并上传 JAR 文件到中心仓库的过程。 #### Maven 构建与 JAR 文件生成规则 在 Maven ...
Maven是一款由Apache软件基金会开发的项目管理和综合工具,它通过POM(Project Object Model)文件来管理项目依赖,提供了一套标准的构建生命周期。然而,Maven虽然普及度高,但其配置文件XML语法相对复杂,且灵活性...
Maven基于项目对象模型(Project Object Model,POM),能够处理编译、测试、文档生成、依赖管理和项目部署等一系列任务。对于“Maven管理的Web项目”,其核心概念和流程主要包括以下几个方面: 1. **项目对象模型...
Maven是Java开发中的一款项目管理和综合工具,它通过XML格式的配置文件管理项目的构建、报告以及依赖关系。"Maven离线依赖包v1"很可能是一个包含Maven仓库中常用库的压缩文件,用于在没有互联网连接或者网络环境不...
Maven 作为一种强大的项目管理工具,极大地简化了 Java 项目的构建和依赖管理过程。通过定义清晰的项目生命周期,Maven 确保了项目的可重复性和一致性。同时,其继承机制也使得大型项目可以更好地组织和管理各个模块...
- 依赖管理由Maven负责,通过POM.xml文件配置项目依赖。 - 开发环境可能包含IDEA或Eclipse等Java集成开发环境。 **学习价值** 对于初学者来说,这个项目提供了一个实际的Spring Boot应用案例,可以从中学到如何设置...
3. **依赖管理**: Maven会自动管理项目的依赖关系,根据POM文件中的声明,从Maven仓库下载所需依赖。如果多个依赖有相同的子依赖,Maven会自动解决版本冲突,按照“最接近依赖”的原则选择版本。 4. **生命周期**: ...
Maven的核心理念是“约定优于配置”,它通过一种标准化的方式来处理项目的构建、依赖管理和文档生成。 **一、Maven项目对象模型(POM)** Maven的项目对象模型(Project Object Model,简称POM)是其核心概念之一...
2. **Maven**:Maven 是一个项目管理和综合工具,它帮助开发者构建、依赖管理和项目信息管理。在本案例中,Maven 负责管理 Shiro 相关库和其他依赖的版本,构建项目的编译、测试和打包过程。 3. **Shiro-maven**:...
它提倡"约定优于配置"(Convention Over Configuration)的原则,对项目的目录结构、测试用例命名方式等内容都做了规定,使用Maven管理的项目都必须遵守这些规则。 Maven具有以下特点: 1. 设置简单。 2. 所有项目...
7. **自定义规则**:对于企业内部的特殊依赖管理规则,MavenHelper还支持自定义配置,确保与团队的规范一致。 总之,"MavenHelper"是Java开发者处理Maven依赖冲突的理想工具。通过它,开发者可以更有效地管理项目中...
1. **统一依赖管理**:通过Parent POM,所有子项目可以共享同一套依赖版本,减少版本冲突,确保项目间的一致性。 2. **减少代码重复**:避免在每个子项目的POM中重复定义相同的插件、配置和属性,提高代码的可维护...