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的强大之处,远不止于此,待下回分析~~