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>
等下次我们需要升级我们的版本时，只需要在父模块中更改，这样不是一劳永逸嘛~~
来自：http://www.cnblogs.com/WJ5888/p/4354064.html