一,依赖原理分析
Jar依赖问题分析:maven的依赖管理,使用的是就近优先、顺序优先原则,
maven依赖可以比作一个依赖树,项目本身可以看作root节点,如下图
1,就近优先:即groupId和artifactId相同时,距离root越近的节点,maven优先选取
例如上图:n11和n22如果groupId和artifactId相同,那么maven优先依赖n11 jar的版本
2,顺序优先:即groupId和artifactId相同时,谁排在前面,优先选取
例如上图:如果n21和n23的groupId和artifactId相同,那么maven优先选择n21这个jar的版本
maven里xml dependency的顺序即决定依赖顺序,如图,n11和n12为直接依赖,n21,n22,n23为间接依赖,
间接依赖的顺序由上层依赖出现的顺序决定,依次排序,groupId和artifactId相同优先排除
二,依赖管理
1,我们遇到的问题
1)无匹配类,无匹配方法
2)某个方法与预期效果不同
3)无相关类,无相关方法
2,导致问题的原因:依赖冲突
3,问题的本质:
1)无规范开发人员的行为:开发人员可以随意添加依赖,未严格规范
2)开发人员疏漏,a)未检查已存在不同版本依赖,b)未检查引入的间接依赖与已有依赖的冲突
4,如何解决依赖问题?(抛砖引玉)
从3中我们知道,导致依赖问题的本质是 a)依赖管理制度 b)开发人员疏忽
为了杜绝依赖管理的混乱,暂如下措施,抛砖引玉,集思广益,大家补充
1)抽取modules公共依赖jar,放到parent中统一管理,例如:
日志框架:commons-logging,log4j,slf4j
常用工具类:commons-lang,commons-codec,commons-collections
框架核心依赖:spring,hibernate 等等
2)限制添加依赖随意性
a) 添加依赖前,仔细检查已有类库是否满足要求。b)评估依赖的应用范围应用频率。
c) 该依赖的功能自定义实现的难易程度
3) 添加依赖前严格检查:请借助eclipse的强大功能,打开dependency hierarchy使用filter
a)检查该依赖是否已经存在
b)添加你需要的依赖,然后打开dependency hierarchy 利用filter,检查添加依赖的间接依赖是否已经存在,
如果存在 排除!如果不存在,在pom文件内直接声明,明确该依赖,然后再排除间接依赖
c)类库的升级检查:当升级类库版本时,循环步骤a,b
d)选择兼容类库:当多个类库依赖同一类库时,运行期测试,是否能正常工作,选择兼容类库
e)根据经验排除类库: 例如cps-ops如下图
上图中hdiv-jstl-taglibs由于间接依赖,引入spring2.5,spring2.5这是一个完全类库,包含beans,core,aop等等
groupId,artifactId分别为:
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
表面上看并未与artifactId为spring-core,spring-bean,spring-aop,spring-web的artifact等冲突,eclipse也未提示conflict,
但当部署的时候,spring2.5.jar和spring-core,spring-bean,spring-aop,spring-web同时存在运行环境,因此导致混乱
根据经验排除冲突jar