http://blog.csdn.net/bluishglc/article/details/6584678
maven传递依赖的版本确定规则，也就是对重复的间接依赖的包的选择规则：
1. 在工程的依赖树上，深度越浅，越被优先选择。如本例中的spring-jms. 由于pom中直接声明了3.0.2版本的spring-jms,所以3.0.2版本的spring-jms在工程的依赖树上处在第一层，而activemq-optional所间接依赖的3.0.3版本的spring-jms则是处在工程依赖树的第二层，则maven会以深度浅者优先，所以最后解析的结果是选择了3.0.2版本的spring-jms。
2. 若两个依赖包处于依赖树上的同一层，则谁在前，选择谁。如本例中的spring-core.一个是activemq-optional的间接依赖，一个是spring-context的间接依赖，两个依赖都是处在第二层上，但由于是activemq-optional声明在前，所以maven优先选择了activemq-optional所依赖的3.0.3的版本！
3. 避免传递依赖引起版本问题的最佳实践。现在很多的开源框架和工具都开始分模块打包发布，比如spring,hibernate都是如此，而这些模块之间又有可能存在相关的依赖关系，为了避免出现版本不一致问题，比如上例中出现的spring-jms使用的是3.0.2，而spring-core却使用了3.0.3这种情况，需要我们对一个工程直接依赖的某一框架的多个模块都要做出声明，而不要依赖其内部的依赖关系来间接引入。总结起来就昌：一般来说，如果工程直接依赖到某一框架的多个模块，最好全部声明这些依赖。