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

Question

我们的团队正在围绕图书馆知识库的问题努力工作。我使用过Maven，并且我熟悉常春藤。我们毫不怀疑，对于第三方罐，集成到构建系统中的公共存储库具有巨大的优势。

围绕着如何处理严格内部的工件而奋斗。我们有很多使用Maven等一些不同构建工具的工件，但实质上它们都是一个产品的一部分（一个团队负责所有这些工具）。不幸的是，我们目前没有为每个项目生产一件神器，但我们正朝着这个方向前进。开发人员会检查所有项目。

我们看到两个选项：

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

2）每个项目直接引用其他“兄弟”项目。有一个“主项目”通过适当的依赖性顺序触发所有其他项目的构建。在IDE（eclipse）中，每个项目直接引用它的依赖项目（源代码）。构建工具查看引用.jar的兄弟项目。

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

但是，它增加了一个负担，因为您必须单独发布更改。在我们的例子中，我们只是想承诺源代码控制（我们每天做20到50次）。

我知道，Maven的可能解决所有这些问题，但球队不将一切转换成Maven的。除了maven，你有什么建议（以及为什么）？

Answer 1

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

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

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

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

Answer 2

没有必要只选择其中一个选项。我成功地将两者结合使用。如果一个项目由多个模块组成，它们全部构建在一起，并且然后被传递到存储库。但是，上传仅适用于“官方”或“发布”版本。正在进行的开发构建是在开发人员的机器上完成的。你不必为此使用Maven。常春藤会工作，甚至手动过程。 “工件存储库”可能是优秀的products可用或只是文件系统挂载点之一。

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

当您说“开发人员会检查所有项目”时，没关系。你永远不知道什么时候你可能想要改变;准备工作拷贝没有任何坏处。但是，你是否真的想让每个开发人员在本地构建每个工件，即使他们不需要改变它？真的，每个开发者都在改变每一件神器吗？

或者，也许你只是没有一个非常大的产品或一个非常大的团队。在有许多子项目（本身可能有子模块）的单个项目中开发没有任何问题。每个人都在一起工作。从顶部一个单一的“全部构建”完成这项工作。简单，工作，快（足够）。那么在这种情况下你会使用共享库吗？可能没什么。

也许你需要等到你的项目/团队变得更大，然后才能看到从分裂中获益。但我向你保证：你有一些基本的组件，这些组件依赖于许多项目（直接或间接），但它们本身并不依赖任何内部工件。理想情况下，这些组件在典型的开发周期中变化不大。我对你的建议是双重的：

1. 建立一个内部存储库，因为你已经同意你会从中受益，如果只为第三方jar。
2. 考虑的最根本的项目分成单独的生成，并提供其神器（S）到仓库，然后有系统的其余部分引用它仿佛它是一个第三方的神器。

如果像这样的分割工作，您会发现只在需要时才重建该基本部分，而项目其余部分（对于开发人员）的构建周期会更快一个相应的数量：双赢。此外，您可以针对基本组件使用不同的交付时间表（如果需要），使其更加慎重和可控（这与应用于此类组件的情况相同）。这有助于促进增长。