我们有许多产品由大量模块组成，其中一些模块在某些产品之间共享。它们分布在几个版本控制库中。版本控制中多模块源项目的声明性依赖性处理
产品由主Ant脚本构建，负责检出所有模块并按正确顺序构建它们。这些模块没有自己的发布周期。
现在，我非常想去声明性依赖管理，但似乎所有解决方案（Maven，Ivy）都依赖于工件而不是版本控制下的源代码。根据文物会让我们头脑发热，所以我宁愿不要。我想要像Ivy这样的产品，但是我可以说我的产品依赖于foo，bar和baz模块（分支2.0），它会检查源代码来自一个或多个源代码管理器（在某些配置中指定）以一个平坦的工作区。
我打算使用gradle这个建设，使之与适合的解决方案，将不胜感激......
摇篮嵌入常春藤项目为它的依赖性管理，所以您将面临同样类型的问题。
依赖管理是一种机制，可以将大型整体构建分解为更小的组件构建，每个构建将其输出发布到公共存储库供其他相关模块使用。
所以这意味着你必须首先做出一个决定，打破你的大型构建，或者干脆使用依赖管理来控制第三方开源库。
假设你有过的事实，你有多个SCM仓库，我可以推荐以下方法来创建一个集中的构建没有控制（我假设你使用ANT +颠覆）：
1） 创建一个包含子模块的主项目
2）每个子模块作为external定义添加到主项目中。这使得主的一个收银台，反过来，结账每个孩子的项目自动
3）的build.xml主项目包含使用常春藤buildlist的任务就是建设子项目按照正确的顺序构建文件基于各个子项目ivy.xml文件中声明的依赖关系。
多项目构建的一个例子是here
我觉得Refix是你所追求的：http://refix.codeplex.com/
摇篮的“项目依赖”是我需要的东西（我认为）在正确建立模块订单和参考内置罐子，一旦检出所有东西。 svn：外部可能会工作，但我不是很喜欢必须在多个位置指定依赖关系。此外，它是静态的，不允许检出时间魔术，如“获取与我其他模块相同的命名分支，如果存在，否则获得中继”。 在我下定决心之前，我正在采取更多的建议......:) – simon 2010-06-22 08:37:41
Gradle中的多项目构建工作方式相同 http://www.gradle.org/0.9-preview-3/docs/userguide/multi_project_builds.html – 2010-06-22 19:35:07