屏上得来终觉浅，绝知此事要躬行
总结：
1.maven项目可以简单的通过在pom文件写入依赖的ID+版本号去依赖目标maven项目而且可以直接使用 无需import但被依赖项目每次更新之后都要重新打包！
2.C->B B->A 此时如果C中想依赖A和B 仅需在pom中配置B即可 会自动导入A
3.当在B 中对A的依赖声明为optional <optional>true</optional> 此时C引用B时，Maven并不会将A作为transitive依赖自动加入
4.C->B->A1 C->A2. 此时C中默认导入离得“近”的项目 此时导入A2
5.B->A1 B->A2 在我的环境中(IDEA2017)默认导入后写的pom 依赖
6.接上C->B 此时显然C中会导入4中的那个依赖 即:后写的依赖
7.B->C->A1 B->D->A2 此时B中会导入先写的pom 依赖中的A 即：先写C 导入A1 先写B导入A2
测试点1：本地Maven项目之间的引用
当前maven项目B 依赖另外两个maven项目A和C A/C项目新建之后B还无法引入依赖，一定要项目install之后 B才能读取依赖 并引入jar包
TestClassA TestClassC 均为上述两个maven项目中的类 可见现在已经可以直接使用这两个类
测试点2：B->A "->"表示依赖于 C->B 那么C中是否可以直接引用A 而无需在pom文件中引入A
当在B 中对A的依赖声明为optional <optional>true</optional> 此时C引用B时，Maven并不会将A作为transitive依赖自动加入
B->A
C->B
可见此时A的jar包已经自动导入进当前依赖中了 而pom中仅仅描述了对B的依赖 显然项目可以直接使用A 如下图
测试点2成立
测试点3：B->A1 C->B 且C->A2 A2表示A1的升级版本 此时C调用A中类如何取舍
可以看到此时自动将之前的testClassA:1.0-SNAPSHOT 替换掉了
显然此时不会冲突自动使用用新的TestClassA
测试点4 ：B->A1 & B->A2 C->B 此时项目C的External Libraries会怎么样？ 此时再去使用TestClassA 怎么办？
可以看到此时虽然B依赖了两个版本的A 但是项目只选取了2.0
见证奇迹的时刻，调换两个依赖在pom中的位置，此时依赖变成了1.0 = =、还以为是默认选取高版本 看来是后来者居上
看看此时C里的情况
case1: C 依赖B 显然会引来后来居上的那个版本 不过项目B需要重新install一发 C才能反映过来B中的变化
case2：c 依赖b 并且依赖a2 该case排除了后来居上的因素 项目C此时依赖的是2.0 可见此时项目会选取更加“近”的版本！
测试点5 B->C->A1 B->D->A2 此时如何处理A？还是按照后来居上？
=======遇到了玄学问题 马丹 C->B->A C中自动导入A 反过来B->C->A B中只有C没有A ？？？？？？ ===================
====神tm囧 还大呼小叫的 让室友来帮忙看这个玄学问题 结果是因为C里面的代码有报错 maven编译的时候 根本不能打成jar包 B找到的还是本地库中的老包 所以不显示A 这你妹 以后遇到玄学问题 不要过于自信 多去找找自己代码的原因 稳住！ maven编译的那个错误也是不太明显，======
好了 我们继续测试 可以看到此时项目B默认导入的是上面的那个项目的依赖A 即A2
在上面的依赖中添加<exclusion> 此时项目C导入的依赖为A1
测试点6：在项目中调用依赖项目的函数
此时项目B依赖C和D 在方法中调用了C和D的两个方法 分别使用了CD各自依赖的A中的方法 此时项目导入的A为1版本
C中方法的A为2版本 此时运行程序会报错 显然此时无法找到A2中的方法
=========== 修仙去了，明天再做总结======================