构建系统中的直接依赖与传递依赖

Question

我正在研究maven的构建系统，它添加了许多传递依赖，因为它的传递依赖系统(maven本身不添加依赖，但传递依赖系统添加)。我看到了一些问题，比如主要的版本冲突和未知的依赖关系。

我在想为什么系统是这样设计的，为什么不采用直接依赖关系。我的库不需要依赖于我的依赖项正在使用的东西，而不是我的库(我的意思是，我理解为什么它需要包含在构建列表中，我的依赖项需要使用这些构建，但为什么它需要导致主要版本冲突？)我是不是遗漏了什么基本的东西？我能想到的一件事是，我的库的构建依赖列表可能会变得非常大，因为我需要接受所有的直接依赖，但这似乎与传递依赖系统的问题一样大。

我刚开始构建系统，所以请不要太苛刻。我也尝试在谷歌上搜索这个问题，但没有找到有用的答案，但请随时评论我可能遗漏的任何问题。

谢谢

Answer 1

如果您需要库A来运行，而库A需要库B来运行，而这需要C来运行，那么弄清楚这一点并将所有相关的依赖项添加到您的项目中是非常繁琐的。

在Maven和Gradle出现之前，许多人以这种方式工作，并发现让构建工具找出传递依赖要容易得多。

Answer 2

我的库不需要依赖于我的依赖项正在使用的东西，而不是我的库...

这是你的主要误解。有两种可能性：

库的直接依赖项

1. 在其公共API中从传递依赖项中公开类型。要使用此公共API，您需要访问这些类型，因此您需要在编译时传递依赖项。

库的直接依赖只在内部使用它自己的依赖，而不是在它的公共

• 中。在这种情况下，您的库在编译时不需要依赖于传递依赖项。但是，一旦您的库代码运行(即使在测试中)，它可能会使用其直接依赖的某些功能，而这些功能在内部使用传递依赖的功能，从而导致您的库代码失败。

...我的意思是，我理解为什么它需要包含在构建列表中，我的依赖项需要使用这些...

外部依赖项没有实际的构建列表(或顺序)，因为它们在已经构建时使用(下载的.jar文件包含已编译的.class文件)。但正如我上面提到的，在编译时或运行时(例如测试)期间，您将需要传递依赖项，因此您的构建系统(Maven或Gradle)将为您获取它们。

...但是为什么需要引起主要版本冲突呢？

@khmarbaise已经解释了in his comment，为什么以及如何在传递依赖之间发生版本冲突：

你正在使用两个库X和Y，它们都使用另一个库(A)，所以X在版本1.0.0中使用A，而Y在版本2.0.0中使用A。最后，您不能在类路径上同时拥有这两个版本，必须为一个版本做出决定。因此，根据X、Y的实现方式，在V1.0.0中使用A时X可能会失败，或者在V1.0.0中使用A时Y可能会失败，或者在V2.0.0中使用A时Y可能会失败...如果正在更新X或Y，则可能会发生这种情况。对于不同的版本组合也是如此，如1.0.0和1.1.0中的A(如果兼容性不是100%)