maven实现依赖的“全局排除"
，只是......可惜......maven目前还不支持，虽然承诺未来会支持(最新的3.1.0依然未提供)。那能不能让我做了一次排除之后可以有个地方记录下确实不能有这个依赖进来，如果出现的话，构建神马的操作就报错提示。嗯，好想法，maven插件可以这个，写个吧。好在maven提供了相应的插件——maven-enforcer-plugin，去尝试帮助开发人员解决这个问题，其中一项比较有用的功能是bannedDependencies，可以设置依赖黑白名单，如果有依赖匹配了黑名单中的依赖设置，那么maven会停止(可以配置)当前操作(打包构建，甚至是mvn eclipse:eclipse)，打印错误日志提示，配置的样式如下：

。使用这个，就可以只排除一次冲突，并记录到黑白名单，下次被破坏的时候，自然会提示信息，这样算是把经验总结下来，一次辛苦，万世留名，我们系统到现在还在使用这个，利器。

?

? ? ? ?到此，看起来我们解决这个全局排除的难题，真的吗？仔细想想，这个也只是一个防御的方式，正像之前说的一样，一个热门的依赖会经常被间接依赖进来，那是不是会经常就构建失败了，有木有一种方式更加彻底(让不允许被依赖的jar直接进不来)呢？当然，方法是有的。不过在将这个之前，还是得穿插一下maven依赖仲裁的原则：maven在解析依赖的时候，有两个原则，第一原则是路径最短有限原则，例如A-->B-->C-1.0(A依赖B，B依赖C的1.0版本)，同时A-->D-->E-->C-2.0，那么从A来看，最终会依赖C的1.0版本进来，因为路径最短，最可信，这个例子也推翻了“高版本覆盖低版本”的错误言论。第二原则是优先声明原则(pom中的声明顺序)，这是对第一原则的补充，就是路径长度相同(第一原则好无力)的情况下，第二原则开始决策微调，不过这个原则是在maven2.1.0才加入的，之前的版本如果第一原则无力的情况下，就是不可调控的，所以码农门升级吧。原则清楚之后，我们就拿阐述第一原则的例子开始，加入A就是你的应用，C就是不允许被依赖进来的一个依赖，咋办？排除&加入黑名单。嗯，很好。那如果我根据第一原则，在A的pom中直接声明C呢？啥？你疯啦？不允许依赖，你还直接声明之？嗯，我确实不想活了，看下声明

?