Maven 引入的传递性依赖机制，一方面大大简化和方便了依赖声明，另一方面，大部分情况下我们只需要关心项目的直接依赖是什么，而不同考虑这些依赖会引入什么传递性依赖。但有时候，当传递性依赖造成问题的时候，我们就需要清楚地知道该传递性依赖是从哪条路径引入的。
例如，项目 A 有这样的依赖关系：
A -> B -> C -> X(1.0)
A -> D -> X(2.0)
X 是 A 的传递性依赖，但是两条依赖路径上有两个版本的 X，那么哪个 X 会被 Maven 解析使用呢？两个版本都被解析显然是不对的，因为那会造成依赖重复，因此必须选择一个。Maven 依赖调解（Dependency Mediation）的异地原则是：路径最近者优先。该例中 X(1.0) 的路径长度为 3，而 X(2.0) 的路径长度为 2，因此，后者会被解析使用。
依赖调解的第一原则不能解决所有问题，比如这样的依赖关系：
A -> B -> Y(1.0)
A -> C -> Y(2.0)
Y(1.0) 和 Y(2.0) 的依赖路径长度是一样的，都为 2，那么到底谁会被解析使用呢？在 Maven 2.0.8 及之前的版本中这是不确定的，但是从 2.0.9 开始，为了尽可能避免构件的不确定性，Maven 定义了依赖调解的第二原则：第一声明者优先。在依赖路径相等的前提下，在 POM 中依赖声明的顺序决定了谁会被解析使用，顺序最靠前的那么依赖优胜。该例中，如果 B 的依赖在 C 之前，那么 Y(1.0) 就会被解析使用。