Maven解读:项目依赖管理如何优化

Github地址:https://github.com/zwjlpeng/Maven_Detail

Maven最大的好处莫过于其强大的依赖管理系统,在Pom配置文件中指定项目需要的Jar包的坐标,Maven就可以自动帮我们从中央仓库或者自已的私服下载,当项目中由于依赖的传递性,引入了两份相同的Jar包时,Maven也会根据自已的规则如路径最短,先声明者优先对相同Jar包进行取舍,达到项目类路径中只保留一份Jar包的目的,我们不排队一些粗心的程序员,在同一份Pom配置文件中对相同Jar写了两份不同版本的依赖,就算这种情况,Maven也能完美的解决,不信你试试~~

即然Maven能够完美的解决项目的依赖关系,那为什么我们还需要优化项目的依赖呢?原因大概如下

1.当项目依赖于某一第三方Jar包,而这一第三方Jar包又给我们间接性的带来了大量的依赖,这种间接性的依赖,不仅浪费了磁盘空间,而且也可能带来潜在的冲突,因此我们需要将这些不需要的依赖从项目中排除,对项目进行一个瘦身,这时我们需要对Pom进行优化,再或者,通过间接性依赖获得的Jar包版本过低,而这些低版本的Jar包无法满足我们项目的需求,这时我们也需要将这些低版本的Jar包排除掉,如下是一个示例:

<dependency>
    <groupId>net.sf.spring-json</groupId>
    <artifactId>spring-json</artifactId>
    <version>1.3.1</version>
</dependency>

当我们在项目中通过Maven依赖引入spring-json时,该依赖会给我们带来cglib-full以及低版本的spring,可以将这两个包从项目类路径中排除,只需要将配置更改成如下即可

<dependency>
	<groupId>net.sf.spring-json</groupId>
	<artifactId>spring-json</artifactId>
	<version>1.3.1</version>
	<exclusions>
		<exclusion>
			<groupId>org.springframework</groupId>
			<artifactId>spring</artifactId>
		</exclusion>
		<exclusion>
			<groupId>cglib</groupId>
			<artifactId>cglib-full</artifactId>
		</exclusion>
	</exclusions>
</dependency>

通过exclusion节点可以断开对某一Jar包的传递性依赖,如果要断开某一Jar包的所有传递性依赖,可以这样配置

<dependency>
	<groupId>net.sf.spring-json</groupId>
	<artifactId>spring-json</artifactId>
	<version>1.3.1</version>
	<exclusions>
		<exclusion>
			<groupId>*</groupId>
			<artifactId>*</artifactId>
		</exclusion>
	</exclusions>
</dependency>

2.多模块项目中,当我们将模块依赖的Jar分别定义在各自模块的配置文件中,各模块之间的依赖完全独立,这时可能出现的情况是,模块A与模块B依赖的spring版本完全不同,某天,我们需要对这两个项目的spring版本升级时,才发现我们不得不更改模块A与模块B两个项目的配置文件,当模块数目少时,我们还可以将就着!但是当模块数多了话...,呵呵!这时我们就需要对项目的依赖进行优化,如下是一个示例,

未优化前的项目配置

模块A

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.6.1</version>
</dependency>

模块B

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.4.0</version>
</dependency>

模块A与模块B之间依赖的jedis版本完全不同,当我们需要升级时,只能一个一个的改,那为什么没有一个统一的方式,实现在一个地方更改后,模块A与模块B的依赖版本均自动更改呢,有,Maven给我们提供了,这就是dependencyManagement

dependencyManagement与dependencies节点的区别

Maven已经具备了面向对象的思想,面向对象的三要素就是多态、继承、封装,dependencies与dependencyManagement就涉及到的是继承的思想,在多模块项目中,我们有一些依赖,需要在每一个模块中都需要用到,如果在每一个模块中我们将重复使用的依赖都写一遍,作为一名追求完美的程序员,你能受得了嘛...,受得了的,我也只能呵呵下...,于是pom中就有了继承的概念,在我们父模块的Pom中,将各个子模块都需要的依赖定义在dependencies这个节点中,子模块中只需要继承父模块即可获取该依赖,继承的配置代码如下:

<modelVersion>4.0.0</modelVersion>
<parent>
	<groupId>com.test</groupId>
	<artifactId>ecom_airTicket</artifactId>
	<version>1.0</version>
</parent>
<artifactId>ecom_airTicket_online</artifactId>
<packaging>war</packaging>
<name>ecom_airTicket_online</name>

例如,多模块项目中,各个模块一般均需要Junit测试Jar包,因此在父Pom配置文件中,我们可以将这个依赖写入

<dependencies>
	<dependency>
		<groupId>junit</groupId>
		<artifactId>junit</artifactId>
		<version>${junit.version}</version>
		<scope>test</scope>
	</dependency>
</dependencies>

这样凡是继承该Pom文件的均会在类路径中加入Junit.jar包

再想想,有一些依赖,是各个子模块所特有的,如果放在父模块的POM中进行定义,那么所有继承了该父模块的子模块均会存在该依赖,这样的结果是啥,项目中存在大量冗余Jar包,不但浪费了磁盘,而且也不利于管理,那么就有人说,我将每个模块各自依赖的Jar包定义在各自的Pom文件中,Good Idea!,但是再想想,假如A与B子模块均依赖于某一个第三方Jar包,这时如果要对该第三方Jar包进行升级,就需要变更A与B两个模块中的POM文件,哪一天,一不小心,你只变换了A模块,而忘了B模块,随后又将项目发到了线上,后果...,再试想一下,如果项目中有很多模块依赖于同一第三方Jar包,又有谁能记得信该更改哪些呢~~

于是乎,Maven就给我们提供了dependencyManagement,在dependencyManagement节点中定义的依赖均不会被继承,即然不会被继承,那要它干啥?

答案是dependencyManagement可以统一管理多模块项目中依赖的版本号,能让我们在子项目中引用一个依赖而不用显式的列出版本号,Maven 会沿着父子层次向上走,直到找到一个拥有dependencyManagement 元素的项目,然后它就会使用在这个dependencyManagement 元素中指定的版本号,当然如果子项目定义了一个版本,它将覆盖顶层POM 的dependencyManagement 元素中的版本

如下是一个示例

父POM配置文件

<dependencyManagement>
	<!-- 配置项目依赖 -->
	<dependencies>
		<dependency>
			<groupId>org.apache.zookeeper</groupId>
			<artifactId>zookeeper</artifactId>
			<version>${zookeeper.version}</version>
		</dependency>
		<dependency>
			<groupId>org.opensymphony.quartz</groupId>
			<artifactId>quartz-all</artifactId>
			<version>${quartz.version}</version>
		</dependency>
		<dependency>
			<groupId>oro</groupId>
			<artifactId>oro</artifactId>
			<version>${oro.version}</version>
		</dependency>
</dependencyManagement>

子模块中我们只需要这样写

<!-- 配置项目依赖 -->
<dependencies>
	<dependency>
		<groupId>org.apache.zookeeper</groupId>
		<artifactId>zookeeper</artifactId>
	</dependency>
</dependencies>

等下次我们需要升级我们的版本时,只需要在父模块中更改,这样不是一劳永逸嘛~~

Maven的强大之处,远不止于此,待下回分析~~

时间: 2024-10-06 19:15:13

Maven解读:项目依赖管理如何优化的相关文章

使用maven构建项目和管理依赖

maven现在已经用的很多了,以前总不明白为什么要使用maven,也是最近才明白了它的好处,使用maven可以很大程度上解决像jar包冲突.项目的移植性不好的问题,相比ant功能要强大很多,这次我打算分享一下我使用maven的心得 一  使用maven构建web项目 1  一般情况下新版的Eclipse都安装了maven插件,直接使用就行,如果没有可以先安装maven插件 2 开始创建maven项目 之后点下一步,出现下面的界面,一般情况只需要使用默认设置就OK了 2 选择maven项目的类型,

4.Maven概念模型,maven的生命周期,Maven坐标,依赖管理(依赖范围,依赖声明),仓库管理,私服概念

 1 maven概念模型 2 maven的生命周期,项目构建过程 Maven生命周期就是为了对所有的构建过程进行抽象和统一 包括项目清理,初始化,编译,打包,测试,部署等几乎所有构建步骤 Maven有"三套"相互独立的生命周期,而且相互独立,这三套生命周期分别是: Maven三大生命周期 clean:清理项目的 在进行真正的构建之前进行一些清理工作. default:构建项目的 构建的核心部分,编译,测试,打包,部署等等. site:生成项目站点的 生成项目报告,站点,发布站点 要

eclipse maven 导出项目依赖的jar包

一.导出到默认目录 targed/dependency 从Maven项目中导出项目依赖的jar包:进入工程pom.xml 所在的目录下,执行如下命令: 1.  mvn dependency:copy-dependencies 或在eclipse中,选择项目的pom.xml文件,点击右键菜单中的Run As,见下图红框中,在弹出的Configuration窗口中,输入dependency:copy-dependencies后,点击运行 maven项目所依赖的jar包会导出到targed/depen

maven导出项目依赖的jar包

在进行项目部署时,需要将maven项目所依赖的jar导出到指定目录,本文讲解如何导出项目依赖的jar包 一.导出到默认目录 targed/dependency 从Maven项目中导出项目依赖的jar包:进入工程pom.xml 所在的目录下,执行如下命令: ? 1 mvn dependency:copy-dependencies 或在eclipse中,选择项目的pom.xml文件,点击右键菜单中的Run As,见下图红框中,在弹出的Configuration窗口中,输入  dependency:c

Maven教程3(依赖管理)

Maven教程2(Eclipse配置及maven项目) Maven项目,依赖,构建配置,以及构件:所有这些都是要建模和表述的对象.这些对 象通过一个名为项目对象模型(Project Object Model, POM)的XML文件描述.这个POM 告诉Maven它正处理什么类型的项目,如何修改默认的行为来从源码生成输出.同样 的方式,一个Java Web应用有一个web.xml文件来描述,配置,及自定义该应用,一个 Maven项目则通过一个 pom.xml文件定义.该文件是Maven中一个项目的

Maven配置项目依赖使用本地仓库的方法汇总

Maven配置项目使用本地仓库有以下方式实现: 1.类似本地仓库,但是属于本地依赖,比如某个JAR包是引用第三方的,直接放在了项目的lib文件夹,那么此时可以如下配置项目的POM: <dependency> <groupId>ldapjdk</groupId> <artifactId>ldapjdk</artifactId> <scope>system</scope> <version>1.0</vers

Maven把项目依赖的所有jar包都打到同一个jar中

目录 1 使用maven-shade-plugin 2 推荐: 使用maven-assembly-plugin 3 扩展: Maven安装本地jar包到本地仓库 4 扩展: 手动生成jar包 5 扩展: Linux下运行jar包的几种方式 5.1 阻塞式方式 5.2 后台运行方式 5.3 后台持续运行方式 5.4 其他命令扩展 1 使用maven-shade-plugin (1) 在项目的pom.xml文件中加入如下插件: <build> <plugins> <!-- Mav

使用maven替换项目依赖中的字节码

问题描述 我们偶尔会发现一些开源项目的问题,或者出于其他原因,想在某个dependency的代码中加几行或者删除几行来达到目的. 我这里遇到一个dubbo 2.7.3和open feign冲突的问题 参见 Issue https://github.com/apache/dubbo/issues/3990. 这里不能等官方修复这个问题并发布更新时,怎么让项目正确的跑起来呢? 问题思路 第一种 字节码替换技术?使用bytebuddy,javassist, asm? 这些技术的局限性,就是JVM本身不

Maven01——简介、安装配置、入门程序、项目构建和依赖管理

1 Maven的简介 1.1 什么是maven 是apache下的一个开源项目,是纯java开发,并且只是用来管理java项目的 Svn eclipse   maven量级 1.2 Maven好处 同一个项目,普通的传统项目(24M)而Maven项目只需要(724KB) 分析:maven项目为什么这么小?没有jar. 需要jar吗?肯定需要.没有存在于maven项目里面,jar存在于哪? 1.3 依赖管理 1.4 项目一键构建 编码  编译  测试(junit)  运行  打包  部署 一个 t