为什么我们需要复杂性的依赖管理答案

【问题标题】：why do we need complexity in dependency management为什么我们需要复杂性的依赖管理
【发布时间】：2013-03-06 10:00:53
【问题描述】：

我不确定问题的标题是否正确，但请阅读问题。

在我的大部分工作生涯中（将近 11 年），我一直在研究 C/C++。我们只有 C/C++ 源/头文件，所有依赖项都由 Makefile 管理。事情很简单，易于管理。

在过去的 1.5 年里，我转向了 Java 领域。我感到非常恼火，使用任何新事物最困难的方面是依赖管理器。例如maven, leiningen, builder, sbt, etc etc.

每当我从开源世界下载任何新内容时，都会花费大量时间来设置编译、构建、运行环境。当我使用eclipse时也是如此。为什么不能将所有依赖项与要下载的软件一起放置？为什么像 maven、leiningen 等工具必须建立单独的 Internet 连接才能下载依赖项。我知道 maven 形成了一个本地存储库，并且应该能够在本地找到依赖项，因为它无论如何都会下载整个互联网，但是为什么要使用这个模型。我在防火墙后面，并非所有内容都可以访问，并且这些工具无法下载依赖项。我相信在大多数工作环境中都会出现同样的情况。

最近我开始使用 clojure，而男孩为 clojure 配置 eclipse 一直很痛苦。 leiningen 应该是某种魔法，必须与任何 clojure 开发一起使用。有时感觉学习 leiningen 比学习 clojure 的概念更重要。我为 leiningen 下载了所谓的“独立”jar 文件，因为“自行安装”对我不起作用。但它愚弄了我。一旦我运行“lein”命令，它就会建立互联网连接并尝试下载一些东西。为什么？它甚至不会在不连接互联网的情况下打印帮助菜单。为什么？我不知道，如果不绕过我的互联网防火墙，我就无法满足它的要求，也没有人能告诉我这个家伙想要什么。根本没有别的办法。

每个人似乎都在发明自己的东西。 Java 有简单的 ant，然后去了 Maven，一些项目使用基于 Ruby 的 Builder，Clojure 有 leiningen，Scala 有 sbt。 Go 还有别的东西。为什么？为什么我们在一个已经充满复杂性的世界中需要这种额外的复杂性。为什么不能只有一个工具。

各位Java技术专家请原谅我的咆哮。我相信这个问题会因为那些没有努力理解这些事情的人而被否决和关闭。但请相信我，我已经花了足够多的时间与这种不必要的复杂性作斗争。

我只是想知道其他人如何解决这个问题，或者我是唯一一个面临这些问题的不幸者。

【问题讨论】：

“我相信这个问题会因为那些没有努力理解这些事情的人而被否决和关闭”。我们回答具体问题。我相信这很痛苦，但是您需要将您的问题格式化为有机会得到回答的内容。这个，不能。
问题是为什么我们需要这种复杂的依赖管理，我是唯一面临这些问题的人。如果其他人面临这些问题，可以对此做些什么。感谢您的评论。
有很多问题是可以解决的，但太多的问题无法解决。例如，如果您尝试 std::cout ，C++ 会吐出垃圾。同样，这更像是一个哲学问题，复杂性将继续存在。
同意。但其他人是否面临这个问题？你面临这个问题吗？如果是的话，你能帮助我理解 dep mgmt 吗？尤其是 maven 或 leiningen？谢谢。
你不明白传递依赖管理的目的吗？我觉得这难以置信。只要您尝试升级任何东西，任何具有甚至一些顶级依赖项的重要项目都会成为维护的噩梦。手动执行此操作是一场噩梦。

标签： maven sbt dependency-management leiningen buildr

【解决方案1】：

我猜这个问题不能接受答案。我谦虚地可以为您提供元素，希望它们能帮助您对问题有所了解。

我发现 Java 构建系统主要存在两个问题：

其中一些是声明性的，而另一些则使用脚本
用于构建和执行控制的 Java 工具的碎片化与人员和空间的 Java 管理有关，而不是技术选择。

Maven 是一种以标准方式使用形式语法定义构建的方法的最重要的方法。您的 pom.xml 文件包含的不仅仅是您的构建：它是您的工件、项目元数据、模块和引入的插件的标识。它特别注意依赖项和存储库的声明。 Maven 是声明性的。

对于某些程序员群体来说，这很好，而且他们不会经常创建新项目。它随着时间的推移运行良好，它很好地整合了构建。

Ant 是一个不同的系统，您可以在其中定义将执行的任务，并以特定顺序链接。所有定义都是使用 XML 进行的，实际上，您正在编写脚本并声明它们将如何拼接在一起。

Buildr（完全披露：我是那里的提交者）是一个构建系统，它是在处理需要执行额外步骤和复杂测试的情况下的声明性方法效率低下以及使用 XML 进行构建。它是基于脚本的，强制执行约定而不是配置（期待一些好的默认设置，但如果您需要更改内容，您可以自行驾驶）。

我不熟悉 Gradle 和 SBT，但据我所知，我认为它们扩展和构建了这种方法。

因此，我希望这能让您更好地了解构建工具方面的情况。

没有标准构建工具出现的原因可能与 Sun 没有使用 Java 推出这一事实有关。最终，我认为他们采用了 Ant（我有一些大多数 JSR jar 都是用它构建的）。在这个领域也有一些产品在扩展其中一些构建系统；为维护代码而不是在旁边做代码的人总是会有巨大的差异。

好吧，人们争论。构建系统是开始一场激烈的战争的好方法。我们很难就一个标准达成一致，尽管一些常见元素现在围绕 Maven 工件很好地解决了。

至于需要一遍又一遍地下载互联网，这是一个相当长的故事，但这里有几件事可能会引发不必要的下载：

任何使用 SNAPSHOT 的依赖项都会尝试获取最新的快照。这是一个伟大的计划，但它需要付出代价。您可能依赖于依赖于快照的东西，并因此获得下载。
Maven 不会重新下载工件，但有时会检查 md5。这很容易解决，只需在命令行中使用 -O 选项即可。

像 Buildr 这样的工具是围绕一劳永逸地解决这个问题而构建的。首先，您只下载您所说的内容。其次，除非您要求，否则不会再次建立连接。默认情况下，Buildr 不玩传递依赖游戏，虽然你可以要求它，但你必须明确地这样做。

我希望这能提供有用的信息，并希望您在 Java 土地上的旅程不会那么痛苦。

【讨论】：