内部工件是否属于存储库？

Question

我们的团队正在努力解决有关图书馆存储库想法的问题。我用过Maven，对Ivy也比较熟悉。我们毫不怀疑，对于第三方 jar，集成到构建系统中的通用存储库具有巨大的优势。

争论的焦点是如何处理严格内部的工件。我们有许多工件使用了一些不同的构建工具，包括 Maven，但本质上它们都是一个产品的一部分（一个团队负责所有这些）。不幸的是，我们目前并没有为每个项目制作一个工件，但我们正朝着这个方向前进。开发人员会检查所有项目。

我们看到两个选项：

1）将所有工件（甚至内部工件）视为任何第三方 jar。每个 jar 都会被构建并发布到存储库，其他工件项目引用所有项目的存储库。

2) 每个项目直接引用其他“兄弟”项目。有一个“主项目”，可以按照适当的依赖顺序触发所有其他项目的构建。在IDE（eclipse）中，每个项目直接引用它的依赖项目（源）。构建工具会查看引用 .jar 的同级项目。

很明显，开源世界正在向存储库模型迈进。但在我们看来，他们的需求可能有所不同。大多数此类项目都是非常独立的，我们强烈怀疑用户很少跨项目进行更改。频繁的升级现在更容易让客户跟踪和了解。

但是，它确实增加了负担，因为您必须单独发布更改。在我们的例子中，我们只想致力于源代码控制（我们每天要做 20-50 次）。

我知道 Maven可能可以解决所有这些问题，但团队不会将所有内容都转换为 Maven。除了 Maven 之外，您还推荐什么（以及为什么）？

Answer 1

没有必要只选择其中一项。我成功地将两者结合使用。如果一个项目由多个模块组成，那么它们都会一起构建，然后交付到存储库。但是，上传仅适用于“官方”或“发布”版本。正在进行的开发构建是在开发人员的机器上完成的。您不必为此使用 Maven。 Ivy 可以工作，甚至可以手动处理。 “工件存储库”可能是优秀的产品 可用或只是一个文件系统安装点。

这一切都是为了找出适当的组件边界。

当您说“开发人员会检查所有项目”时，那很好。你永远不知道什么时候你可能想要做出改变；准备好工作副本没有什么坏处。但是您真的想让每个开发人员在本地构建每个工件，即使他们不需要更改它吗？真的，每个开发人员都会改变每一个工件吗？

或者也许你只是没有一个非常大的产品，或者一个非常大的团队。在具有许多子项目（它们本身可能有子模块）的单个项目中进行开发没有任何问题。每个人都一起努力做所有事情。从顶部开始的一个“构建全部”就可以完成这项工作。简单、有效、快速（足够）。那么在这种情况下您会使用共享存储库做什么呢？可能什么也没有。

也许您需要等到您的项目/团队规模更大之后才能看到拆分的任何好处。

但我向您保证：您有一些基本组件，许多项目（直接或间接）依赖这些组件，但它们本身并不依赖于任何内部工件。理想情况下，这些组件在典型的开发周期中不会发生太大变化。我给你的建议是双重的：

1. 设置一个内部存储库，因为你已经同意你会从中受益，即使只是针对第三方 jar。
2. 考虑将最基本项目分离为一个单独的构建，并将其工件交付到存储库，然后让系统的其余部分引用它，就像 它是第三方工件。

如果像这样的拆分有效，您会发现仅在需要时才重建该基本部分，并且项目其余部分（对于您的开发人员）的构建周期相应加快：双赢。此外，您还可以对基本组件使用不同的交付计划（如果需要），从而使对其的更改更加深思熟虑和受控（对于此类组件来说应该如此）。这有助于促进增长。

Answer 2

如果一个项目生成多个 jar 文件（很多都这样），我会仔细考虑（具体情况）每个 jar 是否会被其他项目重用。

如果是，则该 jar 应该作为库进入存储库，因为它允许您将其指定为依赖项，从而促进重用。

如果不是，这将是一个所谓的“多项目”，其中整个项目是由各个部分构建的。各个 jar 可能不需要单独存储在存储库中。只是最终完成的神器。

Gradle 绝对是您的最佳选择：它可以使用 Ant 任务并调用 Ant 脚本，理解 Maven pom 文件，并且可以很好地处理多项目。 Maven 也可以做很多这样的事情，如果你有足够的耐心，Ant+Ivy 也可以。