我们知道，maven的依赖关系是有传递性的。如：A-->B，B-->C。但有时候，项目A可能不是必需依赖C，因此需要在项目A中排除对A的依赖。在maven的依赖管理中，有两种方式可以对依赖关系进行，分别是可选依赖（Optional Dependencies）以及依赖排除（Dependency Exclusions）。
一、可选依赖
当一个项目A依赖另一个项目B时，项目A可能很少一部分功能用到了项目B，此时就可以在A中配置对B的可选依赖。举例来说，一个类似hibernate的项目，它支持对mysql、oracle等各种数据库的支持，但是在引用这个项目时，我们可能只用到其对mysql的支持，此时就可以在这个项目中配置可选依赖。
配置可选依赖的原因：1、节约磁盘、内存等空间；2、避免license许可问题；3、避免类路径问题，等等。
示例：
<project>
...
<dependencies>
<!-- declare the dependency to be set as optional -->
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional> <!-- value will be true or false only -->
</dependency>
</dependencies>
</project>
假设以上配置是项目A的配置，即：Project-A --> Project-B。在编译项目A时，是可以正常通过的。
如果有一个新的项目X依赖A，即：Project-X -> Project-A。此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能，那么就需要在pom.xml中重新配置对项目B的依赖。
<optional>true</optional>代表当前项目对该库有依赖，但是不会传递给该项目的子项目
我们可以使用optional标志，或将scope设置为“provided”。在这两种情况下，依赖关系都将在声明它们的模块的classpath中，但是使用将它们定义为依赖关系的模块不会在其他项目中传递它们，即不会形成依赖传递
二、依赖排除
当一个项目A依赖项目B，而项目B同时依赖项目C，如果项目A中因为各种原因不想引用项目C，在配置项目B的依赖时，可以排除对C的依赖。
示例（假设配置的是A的pom.xml，依赖关系为：A --> B; B --> C）：
<project>
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>
当然，对于多重依赖，配置也很简单，参考如下示例：
Project-A
-> Project-B
-> Project-D
-> Project-E <! -- This dependency should be excluded -->
-> Project-F
-> Project C
A对于E相当于有多重依赖，我们在排除对E的依赖时，只需要在配置B的依赖中进行即可：
<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>
</dependencies>
</project>
参考资料：
1、maven官网：http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
provided和optional的区别
provided和optional的区别，参考如下：
依赖管理是maven提供的主要功能之一。无论我们需要什么依赖，我们只需将它们添加到POM.xml中。由于maven，所有必要的类和资源都会自动添加到项目的classpath中。
在添加依赖项时，我们可以使用optional标志，或将scope设置为“provided”。在这两种情况下，依赖关系都将在声明它们的模块的classpath中，但是使用将它们定义为依赖关系的模块不会在其他项目中传递它们，即不会形成依赖传递。
从语义来上理解
optional
可选的，可以理解为此功能/此依赖可选，如果不需要某项功能，可以不引用这个包。
scope provided
提供的，可以理解为此包不由我直接提供，需要调用者/容器提供。
举个例子说明二者的使用场景和区别
optional
现开发了一个类似Hibernate的框架，叫Summer吧，致敬下Spring，提供了多种数据库方言的支持:mysql/oracle/db2/postgresql...
每种数据库支持也独立了一个module，Summer的依赖中配置了每种数据库的支持包：summer-mysql-support/summer-oracle-support...
但是实际引用此框架/依赖时，并不需要所有数据库方言的支持。此时可以把数据库的支持包都配置为可选的<optional>true</optional>。
引用此框架时，只需按需引入自己需要的方言支持包即可，避免了冗余繁杂的依赖，也降低了jar包冲突的风险。
scope provided
现有一普通Web工程，必然会用到servlet-api这个包。但是实际上这个包一定是由容器提供的，因为我们这个web会部署到容器内，容器会提供servlet-api，如果此时项目中再引用的话就会造成重复引用，会有版本不一致的风险。
maven常用的scope有compile,provided,runtime,test。
1、complie是默认值，表示在build,test,runtime阶段的classpath下都有依赖关系。
2、test表示只在test阶段有依赖关系，例如junit。
3、provided表示在build,test阶段都有依赖，在runtime时并不输出依赖关系而是由容器提供，例如web war包都不包括servlet-api.jar，而是由tomcat等容器来提供。
4、runtime表示在构建编译阶段不需要，只在test和runtime需要。这种主要是指代码里并没有直接引用而是根据配置在运行时动态加载并实例化的情况。虽然用runtime的地方改成compile也不会出大问题，但是runtime的好处是可以避免在程序里意外地直接引用到原本应该动态加载的包。例如JDBC连接池。
总结
二者从功能来看，都做到了依赖不传递。但在语义上表示不同，使用时按场景选择就好。
