假设有这样换一个依赖关系，项目 A 依赖于项目 B，项目 B 依赖于项目 X 和 Y，B 对于 X 和 Y的依赖都是可选依赖：
A -> B
B -> X(可选)
B -> Y(可选)
根据传递性依赖的定义，如果所有者三个依赖的范围都是 compile，那么 X、Y 就是 A 的 compile 范围传递性依赖。
然而，由于这里 X、Y 是可选依赖，依赖将不会得以传递。换句换说，X、Y 将不会对 A 有任何影响。
为什么要使用可选依赖这一特性呢？可能项目 B 实现了两个特性，其中的特性一依赖于 X，特性二依赖于 Y，而且这两个特性是互斥的，用户不可能同时使用两个特性。比如 B 是一个持久层隔离工具包，它支持多种数据库，包括 MySQL、PostgreSQL 等，在构件这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。
项目 B 的依赖声明：
1 <dependency> 2 <groupId>mysql</groupId> 3 <artifactId>mysql-connector-java</artifactId> 4 <version>5.1.10</version> 5 <optional>true</optional> 6 </dependency> 7 <dependency> 8 <groupId>postgresql</groupId> 9 <artifactId>postgresql</artifactId> 10 <version>8.4-701.jdbc3</version> 11 <optional>true</optional> 12 </dependency>
上述 XML 代码片段中，使用 <optional> 元素表示两个依赖为可选依赖，他们只会对当前项目 B 产生影响，当其他项目依赖于 B 的时候，这两个依赖不会被传递。因此，当项目 A 依赖于项目 B 的时候，如果其实际使用基于 MySQL 数据库，那么在项目 A 中就需要显式地声明 mysql-connector-java 这一依赖。
在理想情况下，是不应该使用可选依赖的。