我应该将 jar 依赖项放在共享 repo 上还是只放在源文件上？答案

【问题标题】：should I put the jar dependencies on the shared repo or just the source files?我应该将 jar 依赖项放在共享 repo 上还是只放在源文件上？
【发布时间】：2011-05-30 19:37:43
【问题描述】：

我们有一个 Scala 项目，其中包含少量源文件（Scala 和 Java）以及各种二进制格式（jar 和 DLL）的相当多的依赖项。我想知道我们共享的 git 存储库中应该包含什么。只有源文件（开发人员必须自己下载或以某种方式解决依赖项）或源文件和依赖项？我可以补充一点，依赖项都是第三方的，可以免费下载。

【问题讨论】：

标签： git scala resources

【解决方案1】：

我真的建议不要在 Git 存储库中包含 jar 和 dll：它会使所说的存储库很快变得很大，而且未来的 git clone 不会像使用一个简单的 source 存储库（如“无二进制文件”）。

我会建立一个Nexus 回购和manage your dependencies through sbt。

【讨论】：

我可以补充一点，SBT 在后台使用 Ivy 技术“自动”管理依赖项方面做得非常好，这反过来又依赖于 maven 风格的存储库来获取所有内容。
显然 Nexus 更适合需要内部私有 maven 存储库的大型组织。
@ashy_32bit：作为一个大型组织，我同意你在 Nexus 上使用私有 Maven 存储库。

【解决方案2】：

从其他地方下载依赖项可能会出现问题：我认为，您无法确保下载的版本仍然是您的项目所需的版本。如果依赖项有进一步的开发，它们的接口可能会改变，你会遇到问题。

因此，我建议将依赖项放入 git 存储库，以确保您使用的是一致版本的依赖项。他们不会每周都改变（他们不应该），所以 repo 不会增长得那么快。而且磁盘空间很便宜。所以问题不大。

如果您想节省磁盘空间，您可以将依赖项压缩到一个文件中（因为 jar 已经存档，所以不会有那么大的影响）。

【讨论】：

【解决方案3】：

我们更喜欢将 .jar 文件存储在同一个存储库中，因为

它们很少更新，因此旧库的开销并不多
我们更喜欢独立的包，不想设置自己的 Maven 服务器

【讨论】：

【解决方案4】：

这里有两个问题：

在开发过程中管理依赖项
向用户分发依赖项

如果所有开发人员都能始终如一地访问互联网，并且没有使用代理，这使得除了 Internet Explorer（或 IT 配置的其他应用程序官方）之外的任何东西几乎都无法逃脱，那么只要有可能，我就会拥有它们由 sbt 或 Maven 自动下载，并且不包含在源存储库中。对于无法自动管理的依赖项，我会将它们包含在源存储库中。如果让除了 Internet Explorer 之外的任何东西都通过代理服务器是徒劳的，我会把所有东西都放在存储库中。我在一家大公司工作，最近 sbt 和 Maven 已经能够通过代理了，但我认为过去 Maven 失败了，有很多工具几乎无法通过。

至于分发，我会创建一个构建目标来压缩所需的所有内容，包括依赖项，我很想将其签入 repo，以免丢失。

【讨论】：