【问题标题】:Releasing parts of a multi-module project发布多模块项目的部分内容
【发布时间】:2018-06-19 16:53:36
【问题描述】:

假设我有一个包含三个模块 A、B、C 的多模块项目,其中 A 依赖于 B,B 依赖于 C。

现在假设我对 B 进行了更改。然后我想发布 B 和 A 的新版本。发布 C 会很奇怪,因为它没有改变,它的任何依赖项也没有改变。所以 B 仍然可以依赖于 C 的最新发布版本。

我将如何处理这个问题?还是我的逻辑有缺陷,我应该总是发布所有模块?

【问题讨论】:

  • 我会发布所有模块,以确保一切都符合要求,并且从用户的角度更易于理解。否则,您应该考虑摆脱多模块构建...
  • 我知道,为所有模块提供一个通用版本号并一次构建它们可能是处理多模块项目的最简单方法。对此有你的看法是件好事,因为你比我更有经验。但是我仍然想知道如果您只更改某个点,那么更改 every 模块的版本号是否正确。当然,这取决于多模块项目的大小,如果是 5 个或 50 个项目。

标签: java maven maven-release-plugin multi-module


【解决方案1】:

同意 - C 不需要更新。

如果 B 的接口没有改变,则不需要更新 A。

相反,如果 B 的 接口 确实发生了变化,则 A 必须与 B 同时更新。但是,有时通过保留旧 B 来保持向后兼容性是有意义/风险较小的界面以及添加新界面。然后添加一个针对 A 的技术债项,让 A 在将来某个时候更新以使用 B 的新接口,并删除 B 的旧接口。

【讨论】:

  • 抱歉,这个答案没有解决在 Maven 多模块项目的上下文中应该如何处理这个问题。
  • 此外,我不同意不需要更新 A。 A 的用户在依赖 A 时希望拥有最新的依赖关系。
  • 您能否具体说明我的回答没有解决您的问题?
  • 如果 A 没有任何变化,为什么 A 需要更新,而 B 的接口保持不变。?例如,服务 A 调用服务 B。B 的内部结构可能已经改变,但 A 为什么会关心呢?
  • 你的意思是B被打包成一个jar,并包含在A中?那么是的,需要一个新版本的 A。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-10-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-06-19
  • 2012-03-26
相关资源
最近更新 更多