一，依赖原理分析
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
