【问题标题】:Declarative dependency handling for multi-module source projects in version-control版本控制中多模块源项目的声明性依赖处理
【发布时间】:2010-06-26 00:20:27
【问题描述】:

我们有许多由大量模块组成的产品,其中一些模块在一些产品之间共享。它们分布在几个版本控制存储库中。

产品由负责检查所有模块并以正确顺序构建它们的主 Ant 脚本构建。这些模块没有自己的发布周期。

现在,我非常想进行声明式依赖管理,但似乎所有解决方案(Maven、Ivy)都依赖于工件而不是版本控制下的源代码。依赖工件会给我们带来麻烦,所以我宁愿不这样做。我想要像 Ivy 这样的东西,但是我可以说我的产品依赖于模块 foo、bar 和 baz(分支 2.0),它会从一个或多个源代码管理器(在某些配置中指定)检查源代码到平坦的工作空间。

我计划使用 gradle 进行构建,因此非常感谢您提供适合的解决方案...

【问题讨论】:

    标签: dependencies ivy dependency-management gradle refix


    【解决方案1】:

    Gradle 嵌入了 ivy 项目以进行依赖管理,因此您将面临同样的问题。

    依赖管理是一种机制,它可以将大型单体构建分解为较小的组件构建,每个构建都将其输出发布到一个公共存储库中以供其他依赖模块使用。

    因此,这意味着您必须首先做出明智的决定来分解您的大型构建,或者干脆满足于使用依赖管理来控制 3rd 方开源库。

    假设您无法控制拥有多个 SCM 存储库这一事实,我可以推荐以下方法来创建集中式构建(我假设您使用的是 ANT + subversion):

    1) 创建一个包含子模块的主项目

    2) 每个子模块都作为external 定义添加到主项目。这使得 master 的一个 checkout 可以反过来自动 checkout 每个子项目

    3) build.xml 主项目包含一个构建文件,该文件使用 ivy buildlist 任务根据各个子项目中声明的依赖项以正确的顺序构建子项目 ivy.xml 文件。

    一个多项目构建的例子是here

    【讨论】:

    • Gradle 的“项目依赖项”是我需要(我认为)以正确的顺序构建模块并引用构建的 jar,一旦所有内容都签出。 svn:externals 可能会起作用,但我对必须在多个地方指定依赖项并不满意。此外,它是静态的,并且不允许结帐时间魔术,例如“获取与其他模块相同的命名分支,如果存在,否则获取主干”。在我在这里下定决心之前,我正在接受更多建议...... :)
    • Gradle 中的多项目构建工作方式相同 gradle.org/0.9-preview-3/docs/userguide/…
    【解决方案2】:

    我认为 Refix 是你所追求的:http://refix.codeplex.com/

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2013-08-01
      • 2016-01-27
      • 2016-01-10
      • 1970-01-01
      • 1970-01-01
      • 2021-02-21
      • 2011-10-14
      相关资源
      最近更新 更多