【问题标题】:Maven: develop against version ranges with SNAPSHOTs but release against fixed versionsMaven:使用 SNAPSHOT 针对版本范围进行开发,但针对固定版本发布
【发布时间】:2012-01-15 12:15:25
【问题描述】:

对于任何中等复杂的软件项目,您很快就会得到复杂的依赖链。

考虑以下依赖树:

  A --> B --> C
     `--------^

A 和 B 都依赖于 C。随着每个项目的发展,固定的依赖关系会阻止持续集成。 (例如,如果 C 更新了 A 所需的修复程序,则 B 的依赖项也需要更新...)使用semantic 版本控制,我们可以使模块与版本范围保持一致,而无需不断调整 pom。

[实际上这个图更复杂。我们不需要将所有内容组合成一个多模块项目(或以其他方式组合它们),因为这会破坏模块化。我们希望通过持续集成构建模块化软件。]

但是部署的版本应该是不可变的。他们所依赖的版本应该是固定不变的,所以今天发布的版本(+它的依赖项)与明年使用的版本相同。

目标

  • 开发人员处理 SNAPSHOT 版本(在本地或从 Hudson 选择 SNAPSHOT 依赖项)
  • 根据最新(兼容)发布的依赖项(不包括 SNAPSHOT)版本进行发布
  • 发布是永远不变的。取决于 A=1.0.0 将始终引入相同版本的 B 和 C

问题

  • 在 Maven 中执行此操作的最佳方法是什么?是否有描述此用例的链接/文档?
  • maven 发布插件能否解析版本范围并将它们烘焙到发布中?

鉴于

  • 默认情况下,maven (3.0.3) 在版本范围内选择 SNAPSHOT 依赖项。
  • SNAPSHOT 和版本可以部署到单独的存储库中

有没有更好的方式与 maven 进行持续集成?

【问题讨论】:

    标签: maven maven-3 maven-release-plugin


    【解决方案1】:

    如果任何依赖项是 SNAPSHOT,则发布插件将不会发布。这就是 Maven 如何确保发布是不可变的。创建一个小型的多模块测试项目并在其上运行发布插件。然后你会更好地理解它的行为——这是我必须做的。

    我从事一个包含 405 个 POM 的多模块项目,由 Jenkins 构建并部署到 Artifactory。

    【讨论】:

    • 版本范围是否在发布期间被锁定?如果 A 1.0 取决于 B [1.0,2.0)。该依赖范围是否在版本 A 中持续存在?
    猜你喜欢
    • 2011-06-18
    • 2016-07-24
    • 1970-01-01
    • 2012-01-22
    • 1970-01-01
    • 2010-10-14
    • 2017-11-21
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多