我们的团队正在努力解决有关库存储库的问题。我使用过Maven，我熟悉Ivy。我们毫不怀疑，对于第三方jar，集成到构建系统中的公共存储库具有巨大的优势。
斗争是围绕如何处理严格内部的工件。我们有许多使用少数不同构建工具的工件，包括Maven，但实际上它们都是一个产品的一部分（一个团队负责所有产品）。不幸的是，我们目前没有为每个项目生产一个工件，但我们正朝着这个方向前进。开发人员会检查所有项目。
我们看到两个选项：
1）将所有工件甚至内部工件视为任何第三方jar。每个jar都构建并发布到存储库，其他工件项目引用所有项目的存储库。
2）每个项目直接引用其他“兄弟”项目。有一个“主项目”，可以通过适当的依赖顺序触发所有其他项目的构建。在IDE（eclipse）中，每个项目直接引用它的依赖项目（源）。构建工具会查看引用.jar的兄弟项目。
很明显，开源世界正朝着存储库模型发展。但在我们看来，他们的需求可能会有所不同。大多数此类项目都非常独立，我们强烈怀疑用户很少在项目之间进行更改。现在有频繁的升级，客户可以更轻松地跟踪和了解。
但是，它确实增加了您必须单独发布更改的负担。在我们的例子中，我们只想承诺源控制（我们每天做20-50次）。
我知道Maven 可能会解决所有这些问题，但团队 NOT 会将所有内容转换为Maven。除了maven，你推荐什么（以及为什么）？
答案 0 :(得分：1)
没有必要只选择其中一个选项。我成功地将两者结合使用。如果项目由多个模块组成，则它们都构建在一起，然后 传递到存储库。但是，上传仅适用于“官方”或“发布”版本。正在进行的开发构建是在开发人员的机器上完成的。您不必为此使用Maven。常春藤会工作甚至手动过程。 “工件库”可能是优秀的products可用之一，也可能只是文件系统安装点。
这是关于找出适当的组件边界。
当你说“开发人员会做并将检查所有项目”时，那没关系。你永远不知道什么时候你想做出改变;准备工作副本没有坏处。但是你真的想让每个开发人员在本地构建每个工件，即使他们不需要改变它吗？真的，每个开发人员都会改变每个工件吗？
或者你可能没有一个非常大的产品，或者一个非常大的团队。在具有许多子项目（可能本身具有子模块）的单个项目中进行开发没有任何问题。每个人都在一起工作。从顶部开始的单个“全部构建”完成工作。简单，有效，快速（足够）。那么在这种情况下你会使用共享存储库呢？可能没事。
也许你需要等到你的项目/团队更大，然后才能看到分裂的好处。
但我向你保证：你有一些基本的组件，这些组件依赖于（直接或间接）许多项目，但它们本身并不依赖于任何内部工件。理想情况下，这些组件在典型的开发周期中不会发生太大变化。我给你的建议是双重的：
如果像这样的分割有效，你会发现你只在需要的时候重建那个基本部分，并且项目其余部分（对于你的开发人员）的构建周期相应更快：win-赢得。此外，您将能够为基本组件使用不同的交付计划（如果需要），使对其的更改更加慎重和受控（对于此类组件应该如此）。这有助于促进增长。
答案 1 :(得分：0)
如果一个项目产生了多个jar文件（还有很多），我会仔细考虑（个案）每个jar是否会被其他项目重用。
如果是，那个jar应该作为库进入存储库，因为它允许你将它指定为依赖项，从而促进了重用。
如果不是，那将是一个所谓的“多项目”，其中整个项目是由零件构建的。单个罐子可能不需要单独存储在回购中。只是最后完成的工件。
Gradle绝对是您的候选人：它可以使用Ant任务并调用Ant脚本，理解Maven pom文件，并很好地处理多个项目。 Maven也可以做很多事情，如果你有很多耐心，Ant + Ivy可以。