Question

鉴于我们有一组Maven工件，它们之间存在一些依赖关系。工件由各个团队拥有，可能由几个团队同时拥有。这是我们的大项目。例如：

projectX --- projectA

        |     \
   projectB   projectC

一个问题是：什么更好，将所有子项目保留在一个大型Maven项目中，或者让每个团队拥有自己的工件和自己的发布周期以及自己的版本？

分离团队的好处很简单：如果某个团队未能通过构建 - 其他人仍然使用该团队提供的旧依赖关系并且没有遇到任何问题。此外，在每个全局版本中，我们都会看到哪些模块已更改，并且更容易找到问题。

分离团队的缺点是：

团队A更改projectX。现在所有团队都必须重新发布他们的模块。
projectX＆＃39>的版本是3个模块中的硬编码，这是一个非常容易出错的解决方案。否则，该版本可能在父模块中被描述为LATEST或硬编码，但是如果更改了projectX，谁将强制团队重新编译他们的模块？

那么这种典型情况的最佳做法是什么？

Answer 1

可悲的是，没有一条黄金法则。我参与了一个大项目（大约90个maven模块/子模块......从maven1迁移到maven2！），当时我们在每个版本中都使用了一个大版本，同时使用SNAPSHOT版本进行开发。

但实际上我的观点取决于两个因素：

这真的是管理开发团队的问题，maven的工件版本策略必须遵循管理指南，而不是驱动它（我们必须始终对我们的工具负责！）

释放周期需求

如果需要独立发布项目/模块，强迫其他人在其他模块上做某事是不好的。 Maven versions range dependencies可用于允许其他项目依赖于刚刚发布的工件。

突破界面责任

当我的模块中的更改破坏了另一个团队负责的界面时会发生什么？（或导致测试失败，因为你有集成测试，对吧？！）

我可以更改通话代码吗？我可以更改其他模块依赖关系以明确警告当前版本不再兼容吗？

回答这些问题，恕我直言帮助定义合适的版本政策。