转过路角忽然发现，3岁的儿子已在路口等着自己回来。
在0℃的江苏无锡街头，环卫工用双手疏通下水道。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　了解可选依赖和排除依赖的功能，能够帮助我们更好的理解依赖是什么、怎样使用、如何工作和何时最适宜应用。其中，排除依赖是作为依赖的基本概念而不是处于pom层。
　　一、 可选依赖
　　当一个项目不适合分割成多个子模块的时候，我们可以使用可选依赖。它的思想在于某些依赖只应用于某些功能，而且当没有该功能时也不存在该依赖。理想状况下，一个功能可能被划分为一个子模块，该子模块是一个只有核心功能的项目，由于当你要使用这个子工程的功能的时候，你会需要它的全部，所以这个子工程只含有非可选性依赖。
　　然而，如果工程不可被分割，这些依赖被声明为可选。如果一个用户想要使用和可选性依赖相关的功能，他们必须要在工程中重新声明可选性依赖。也许可选依赖和排除依赖不是解决问题的最好方法，但是不失为一种有效的解决方案。
　　1. 为何使用可选依赖
　　声明可选依赖不仅对于节省空间/内存等是重要的，而且对于使用一个工程的时候控制实际依赖的列表也是非常重要的。因为jar包最终可能编译成WAR、EAR、EJB等等，包含错误的jar包可能产生违反许可证协议、导致类路径错误等问题。
　　2.如何使用optional标记
　　在你的依赖声明中简单地将&optional&标记设置成true，就能将一个依赖声明为可选的。示例如下
　　&project& ... &dependencies& &!-- declare the dependency to be set as optional --& &dependency& &groupId&sample.ProjectA&/groupId& &artifactId&Project-A&/artifactId& &version&1.0&/version& &scope&compile&/scope& &optional&true&/optional& &!-- value will be true or false only --& &/dependency& &/dependencies& &/project&
　　3.可选依赖是如何工作的？
　　Project-A -& Project-B
　　如上图所以projectA依赖projectB，当A在它的pom中声明B作为它的可选依赖时，这个关系会一直保持。 这就像在通常的构建中，projectB会被加到它的类路径中。
　　Project-X -& Project-A
　　但是当另外一个工程projectX在它的pom中声明A作为其依赖时，可选性依赖这时就发挥作用了。你会发现projectB并不存在projectX的类路径中。如果X的类路径要包含B那么需要在你的pom中直接进行声明。
　　4.例子：
　　让我们假设现在有这样一个和Hibernate有类似功能的工程X2，支持多种诸如mysql, postgre, oracle等数据库驱动/依赖,所有这些驱动/依赖是X2但不是你的工程所需要的，所以一种比较可行的方法就是X2将这些驱动/依赖声明为可选的。这样，无论任何时候当你的工程在pom中声明X2作为直接依赖，X2所支持的这些驱动/依赖都不会被自动加到你工程的类路径中，相反地，你必须要直接声明需要使用的数据库驱动/依赖。
　　二、 排除依赖
　　由于maven2.x会传递解析依赖，所以很有可能一些你不需要的依赖也会包含在工程类路径中。例如，一些你依赖的工程可能没有正确的声明它们的依赖集。为了解决这种特殊情况，maven2.x已经引入了显式排除依赖的概念。排除是设置在pom中指定的依赖上，并且有指定的groupId和artifactId来标注。当你构建工程时，该物件不会像解析加载依赖一样被加载到你工程的类路径中。
　　1. 如何使用排除依赖
　　我们在pom中的&dependency&段下面加上&exclusions&标签。
　　&project& ... &dependencies& &dependency& &groupId&sample.ProjectA&/groupId& &artifactId&Project-A&/artifactId& &version&1.0&/version& &scope&compile&/scope& &exclusions& &exclusion& &!-- declare the exclusion here --& &groupId&sample.ProjectB&/groupId& &artifactId&Project-B&/artifactId& &/exclusion& &/exclusions& &/dependency& &/dependencies& &/project&
　　2.排除依赖是如何工作的并且在何时使用它（作为最后一种解决方法）
　　Project-A -& Project-B -& Project-D &! -- This dependency should be excluded --& -& Project-E -& Project-F -& Project C
　　如上图所示，Project-A依赖Project-B和C，Project-B依赖Project-D，Project-D依赖Project-E和F，默认的Project-A的类路径会包含：
　　B, C, D, E, F
　　如果由于我们知道Project-D的某些依赖在仓库中丢失，那么我们不想Project-D和它所有的依赖加载到Project-A的类路径中，而且也不想/不需要依赖Project-D的Project-B的功能。在这种情况下，Project-B的开发者会提供一个Project-D的 &optional&true&/optional&依赖，如下：
　　&dependency& &groupId&sample.ProjectD&/groupId& &artifactId&ProjectD&/artifactId& &version&1.0-SNAPSHOT&/version& &optional&true&/optional&
　　&/dependency&
　　然而，并不能达到你想要的效果。作为最后一种解决方法你仍然可以选择将它在Project-A中排除掉。如下：
　　&project& &modelVersion&4.0.0&/modelVersion& &groupId&sample.ProjectA&/groupId& &artifactId&Project-A&/artifactId& &version&1.0-SNAPSHOT&/version& &packaging&jar&/packaging& ... &dependencies& &dependency& &groupId&sample.ProjectB&/groupId& &artifactId&Project-B&/artifactId& &version&1.0-SNAPSHOT&/version& &exclusions& &exclusion& &groupId&sample.ProjectD&/groupId& &!-- Exclude Project-D from Project-B --& &artifactId&Project-D&/artifactId& &/exclusion& &/exclusions& &/dependency& &/dependencies& &/project&
　　如果我们将Project-A部署到一个仓库中，而且Project-X声明了一个普通依赖到Project-A。那么Project-D是不是依旧从类路径中排除了？
　　Project-X -& Project-A
　　答案是yes。Project-A已经声明了它不需要Project-D，所以它不会作为Project-A的传递依赖而引入。那么考虑下图的Project-X依赖Project-Y，
　　Project-X -& Project-Y -& Project-B -& Project-D ...
　　Project-Y依赖于Project-B，并且它有需要Project-D所支持的功能，所以不能在Project-D的依赖列表中声明排除。也可再提供一个额外的我们可以解析Project-E的仓库。在这种情况下，不能将Project-D全局排除，因为它是Project-Y的合法依赖。
　　在另外一种场景中，如果我们不需要的依赖是Project-E而不是Project-D，我们如何排除它呢？如下图：
　　Project-A -& Project-B -& Project-D -& Project-E &!-- Exclude this dependency --& -& Project-F -& Project C
　　排除会影响到在依赖图上所有它的声明点以后的部分。如果你想排除Project-E而不是Project-D，可以简单的将排除指向Project-E。但是你无法将排除作用到Project-D，因为你无法改变Project-D的pom，如果你想这样，你应该用选择依赖而不是排除，或者将Project-D分成多个子工程，每个只有普通依赖。
　　&project& &modelVersion&4.0.0&/modelVersion& &groupId&sample.ProjectA&/groupId& &artifactId&Project-A&/artifactId& &version&1.0-SNAPSHOT&/version& &packaging&jar&/packaging& ... &dependencies& &dependency& &groupId&sample.ProjectB&/groupId& &artifactId&Project-B&/artifactId& &version&1.0-SNAPSHOT&/version& &exclusions& &exclusion& &groupId&sample.ProjectE&/groupId& &!-- Exclude Project-E from Project-B --& &artifactId&Project-E&/artifactId& &/exclusion& &/exclusions& &/dependency& &/dependencie&
　　3.为什么排除是依赖的基本概念，而不是在pom层上？
　　这主要是为了确保依赖图是可预测的，并且防止排除不该排除的依赖。如果你用到了这个最终的解决方法并且必须要把它放到排除中，你必须绝对清楚你讨厌的传递依赖中有哪些依赖会被引入。
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：Java（44）
转自：http://my.oschina.net/liuyongpo/blog/177301
大多数java应用源码构建和依赖管理是使用maven来实现的，maven也是java构建和依赖管理的事实上的标准。我们的应用系统也都是基于maven构建的，maven虽然在依赖管理方面确实很牛叉，但是并不能很优雅地解决所有依赖的问题，比如此次谈及的“全局排除”功能。
& & & &之前包括现在都在经历这样的事情，想禁止一个依赖被依赖进来，如果这个依赖属于冷门的依赖，很少类库会间接依赖它，那么进行一次排除完全OK，但是如果一个依赖是热门依赖，比如常用的apache的commons系列工具库，单独排除也可以实现，只是比较啰嗦，而且以后引入新的依赖就要时刻关心是否会带来不被允许的依赖，对维护人员来说简直是灾难。
& & & &首先谈下为什么有些依赖是一定不能允许的。在的博文中已经提到了依赖的一个典型特性——互斥，就是说有的依赖之间是不能共存的，比如提到过的slf4j-log4j和logback，guava和google-collection等等，一旦应用选择了使用logback就不能再引入slf4j-log4j依赖，原因可以看日志详解，而guava和google-collection会存在jar冲突，这样的例子还有很多。所以对于经常碰到这种冲突的开发人员来说，强烈希望改善这种局面。
& & & &想象下这样一个场景：你的应用不能依赖slf4j-log4j，别的开发不清楚，引入了其他类库，间接引入了这个依赖，之后应用除了问题，你负责去排查，看到了这个问题，排除了slf4j-log4j，收工。那下次出现了，你再去排除一次，那下下次，嗯哼......对了，我们需要全局声明下，这个依赖不能进来，好想法，只是......可惜......maven目前还不支持，虽然承诺未来会支持(最新的3.1.0依然未提供)。那能不能让我做了一次排除之后可以有个地方记录下确实不能有这个依赖进来，如果出现的话，构建神马的操作就报错提示。嗯，好想法，maven插件可以这个，写个吧。好在maven提供了相应的插件——，去尝试帮助开发人员解决这个问题，其中一项比较有用的功能是，可以设置依赖黑白名单，如果有依赖匹配了黑名单中的依赖设置，那么maven会停止(可以配置)当前操作(打包构建，甚至是mvn
eclipse:eclipse)，打印错误日志提示，配置的样式如下：
&&&&&groupId&org.apache.maven.plugins&/groupId&&
&&&&&artifactId&maven-enforcer-plugin&/artifactId&&
&&&&&executions&&
&&&&&&&execution&&
&&&&&&&&&id&enforce-versions&/id&&
&&&&&&&&&goals&&
&&&&&&&&&&&goal&enforce&/goal&&
&&&&&&&&&/goals&&
&&&&&&&&&configuration&&
&&&&&&&&&&&rules&&
&&&&&&&&&&&&&requireMavenVersion&&
&&&&&&&&&&&&&&&version&2.1.0&/version&&
&&&&&&&&&&&&&/requireMavenVersion&&
&&&&&&&&&&&&&requireJavaVersion&&
&&&&&&&&&&&&&&&version&1.6&/version&&
&&&&&&&&&&&&&/requireJavaVersion&&
&&&&&&&&&&&/rules&&
&&&&&&&&&/configuration&&
&&&&&&&/execution&&
&&&&&&&execution&&
&&&&&&&&&id&enforce-banned-dependencies&/id&&
&&&&&&&&&goals&&
&&&&&&&&&&&goal&enforce&/goal&&
&&&&&&&&&/goals&&
&&&&&&&&&configuration&&
&&&&&&&&&&&rules&&
&&&&&&&&&&&&&bannedDependencies&&
&&&&&&&&&&&&&&&excludes&&
&&&&&&&&&&&&&&&&&exclude&junit:junit&/exclude&&
&&&&&&&&&&&&&&&&&exclude&org.testng:testng&/exclude&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&exclude&com.google.collections:google-collections&/exclude&&
&&&&&&&&&&&&&&&&&exclude&commons-logging:commons-logging&/exclude&&
&&&&&&&&&&&&&&&/excludes&&
&&&&&&&&&&&&&&&includes&&
&&&&&&&&&&&&&&&&&include&junit:junit:4.8.2:jar:test&/include&&
&&&&&&&&&&&&&&&&&include&cglib:cglib-nodep:jar:2.2&/include&&
&&&&&&&&&&&&&&&/includes&&
&&&&&&&&&&&&&/bannedDependencies&&
&&&&&&&&&&&/rules&&
&&&&&&&&&&&fail&true&/fail&&
&&&&&&&&&/configuration&&
&&&&&&&/execution&&
&&&&&/executions&&
从这个插件配置上可以看出，还可以限制java版本以及maven版本。重点看看对依赖黑白名单的生命，黑名单中规定不能引入commons-logging，那么一旦依赖了这个，操作会提示，至于是不是会停止操作，取决于下边fail标签中的配置。比较特殊的是黑名单中排除了junit，而白名单中更加详细地描述junit，这个可以这么解读：不允许依赖junit，除了版本是4.8.2的scope为test的junit，从此可以看出，白名单是对黑名单的补充，这样更加灵活。当我看到这个插件的时候，它还在襁褓中(beta版)，但是强烈吸引到了我的注意，这娃必成大器。使用这个，就可以只排除一次冲突，并记录到黑白名单，下次被破坏的时候，自然会提示信息，这样算是把经验总结下来，一次辛苦，万世留名，我们系统到现在还在使用这个，利器。
& & & &到此，看起来我们解决这个全局排除的难题，真的吗？仔细想想，这个也只是一个防御的方式，正像之前说的一样，一个热门的依赖会经常被间接依赖进来，那是不是会经常就构建失败了，有木有一种方式更加彻底(让不允许被依赖的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呢？啥？你疯啦？不允许依赖，你还直接声明之？嗯，我确实不想活了，看下声明
&dependency&&
&&&&&groupId&C&/groupId&&
&&&&&artifactId&C&/artifactId&&
&&&&&version&2.0&/version&&
&/dependency&
这样是不是意味着，间接依赖的C都不顶用了，但是直接依赖了C，还是违背了不能依赖C的大前提，好，继续看下，把依赖声明改下
&dependency&&
&&&&&groupId&C&/groupId&&
&&&&&artifactId&C&/artifactId&&
&&&&&version&2.0&/version&&
&&&&&scope&provided&/scope&&
&/dependency&
啊哈，这样C就不会打进最终的war包啦，也就间接起到了“全局排除”的目的。但是这样会给人造成迷惑，会什么是2.0，其实这个版本号已经没有任何含义了。但是问题还是在的，虽然声明了provided，但是编译时，这个jar依然还会出现在classpath下的，那代码依然开始可以引用的。那就再进一步，弄一个C的空壳，里边啥都没有，比如可以自己新建一个空的maven工程，C:C：empty_version，然后上传到私服(一般公司都会有自己的私服的)上，引用的地方改成把版本改成empty_version。这样对于A来说，因为是直接依赖C的empty_version版本，那么间接依赖全部自动被仲裁掉了，以后也不用担心别人引入依赖间接导致问题了。这样的做法并不完美，毕竟需要在私服上上传一个“垃圾”依赖，应用代码还需要直接依赖这个“垃圾”依赖。
综合黑白名单的方式和最后一种方式，总结下，如何结合使用。对于不那么热门的依赖，建议走黑白名单，毕竟很少出现，出现一次，手工排除下很简单。对于热门的依赖，也分下情况，像guava&google-collections这种情况，因为前者的代码是后者的超集，所以当依赖了guava的情况下，可以直接声明google-collections为provided，不需要上传一个空包，但是假如guava删掉了一些api，即它不再是超集的时候，就会出现问题。像logback&slf4j-log4j&slf4j-jdk14这种依赖，没有谁是谁的子集的说法，所以建议直接上传空包排除即可。当然这些原则还是需要开发者自己去权衡的。一定不是“一刀切”的原则，一刀切固然可以很好执行，但是往往不是最优的，两者或者多者结合，取长补短才是合理的，但是也会带来迷惑，因为有了选择。不过可以参考上边的总结，我们的应用也是两者结合的方式，选择的原则也是按照上边描述的，当然，最终的选择权还是交给你，enjoy
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：118415次
积分：1779
积分：1779
排名：第18218名
原创：32篇
转载：189篇
(1)(2)(3)(6)(9)(7)(7)(2)(4)(3)(5)(4)(1)(6)(8)(6)(9)(6)(6)(9)(3)(4)(5)(5)(5)(13)(21)(1)(3)(6)(11)(5)(5)(17)(16)学习（14）
引用自:/dongqingswt/p/3457702.html
今天遇到要全局排除一个maven依赖，因为Maven本身没有全局排除依赖的办法，
参考了同事人英写的一篇博文（可以看这里http://my.oschina.net/liuyongpo/blog/177301）
总结下来是两种办法：
1、在maven服务器部署一个需要排除的依赖的空jar .
2、使用&加排除黑名单。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：20859次
排名：千里之外
原创：40篇
转载：13篇
(4)(8)(3)(1)(8)(12)(9)(4)(3)(1)MAVEN3--(二)安装MAVEN -
- ITeye技术网站
博客分类：
1.安装要求
JDK5及以上版本
2.下载MAVEN安装包
下载地址：
安装过程如下：
1）解压ZIP文件
2）配置系统环境变量M2_HOME,指向MAVEN的安装目录
3）系统环境变量PATH中增加%M2_HOME%\bin
4）新开一个CMD窗口，输入MVN -V进行安装验证
3.安装目录分析
主要包含一些mvn运行脚本
包含类加载器框架
本地全局定制Maven的配置文件setting.xml，不过建议不做修改
包含了Maven运行时需要的JAVA类库
并且可以在maven-model-builder-3.0.4.jar\org\apache\maven\model中找到超级POM文件
|-LICENSE.TXT
|-NOTICE.TXT
|-README.TXT
4.安装ECLIPSE插件
1）安装地址：
2）安装后设置MAVEN的安装路径，而不要使用插件自带的MAVEN
Window-&Preferences-&MAVEN-&Installations
5.MAVEN_OPTS环境变量
由于Maven命令实际上是执行了Java命令，所以可以通过JAVA命令参数的方式来设置MAVEN运行参数。
MAVEN_OPTS环境变量正是用于此用途
MAVEN_OPTS
-Xms128m -Xmx512m
分别设置JVM的最小和最大内存
提示：上诉要求当然可以通过修改Maven脚本实现，但是不推荐，因为升级时不方便，
所以推荐尽可能不去修改任何Maven安装目录下的文件。
orange5458
浏览: 200857 次
来自: 深圳
大神，你分享的castor dtd文件中没有field-han ...
建议举些通俗的例子，说明下。光这样讲，不好懂。
1.不在不同的机器上实现集群功能，除非他们的时钟同步精确到秒。 ...
可以参考最新的文档：如何在eclipse jee中检出项目并转 ...
写的不错，借用啦，哈哈，多谢！