关于大型项目版本控制和避免包含表达式的版本的Maven建议

我正在考虑重组一个大型Maven项目

我们当前结构的基本概述：

build [MVN plugins, third party dependency management]:5.1
   NRW Utils:6.0.0.0-beta12-SNAPSHOT
      server-utils:6.0.0.0-beta12-SNAPSHOT
      ... 
   CMW Root:6.0.0.0-beta12-SNAPSHOT
      cmw-webapp:6.0.0.0-beta12-SNAPSHOT
      cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT
      ...
   NRW Root :6.0.0.0-beta12-SNAPSHOT
      nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT
      ...

build [MVN plugins, third party dependency management]:5.1
   nrw-version-management:6.0.0.0-beta-SNAPSHOT
      [contains properties defining latest versions of each collective module]   
      NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT
         server-utils:6.0.0.0-NU-beta4-SNAPSHOT
         ... 
      CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT
         ...
      NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT
         nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT
         ... 

更改原因：

build [MVN plugins, third party dependency management]:5.1
   NRW Utils:6.0.0.0-beta12-SNAPSHOT
      server-utils:6.0.0.0-beta12-SNAPSHOT
      ... 
   CMW Root:6.0.0.0-beta12-SNAPSHOT
      cmw-webapp:6.0.0.0-beta12-SNAPSHOT
      cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT
      ...
   NRW Root :6.0.0.0-beta12-SNAPSHOT
      nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT
      ...

build [MVN plugins, third party dependency management]:5.1
   nrw-version-management:6.0.0.0-beta-SNAPSHOT
      [contains properties defining latest versions of each collective module]   
      NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT
         server-utils:6.0.0.0-NU-beta4-SNAPSHOT
         ... 
      CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT
         ...
      NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT
         nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT
         ... 

每个集合模块（即NRW UTIL、CMW根和NRW根）的大小越来越大，构建过程开始花费难以忍受的时间（有时约4小时）

新计划：

build [MVN plugins, third party dependency management]:5.1
   NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT
      server-utils:6.0.0.0-NU-beta4-SNAPSHOT
      ... 
   CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT
      cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT
      cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT
      ...
   NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT
      nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT
      ...  

我们已经开始在版本中引入“键”，以区分不同的“集体模块”，因此可以轻松执行分级发布。此外，我们的实用程序模块更加稳定，因此我们可能不需要那么多的beta版本-现在对保持beta数字同步没有任何限制

还值得注意的是，事实上有5个不同的“集合模块”（不仅仅是3个），所有模块都将使用不同的版本（以唯一键区分）构建，这就是为什么我认为最好有一个集中的版本位置，而不是在5个不同的POM中复制属性

现在的问题在于在不同版本的不同“集合模块”中定义模块依赖关系时POM文件的内容

推荐的依赖项版本管理解决方案：

build [MVN plugins, third party dependency management]:5.1
   NRW Utils:6.0.0.0-beta12-SNAPSHOT
      server-utils:6.0.0.0-beta12-SNAPSHOT
      ... 
   CMW Root:6.0.0.0-beta12-SNAPSHOT
      cmw-webapp:6.0.0.0-beta12-SNAPSHOT
      cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT
      ...
   NRW Root :6.0.0.0-beta12-SNAPSHOT
      nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT
      ...

build [MVN plugins, third party dependency management]:5.1
   nrw-version-management:6.0.0.0-beta-SNAPSHOT
      [contains properties defining latest versions of each collective module]   
      NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT
         server-utils:6.0.0.0-NU-beta4-SNAPSHOT
         ... 
      CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT
         ...
      NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT
         nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT
         ... 

nrw版本管理（pom.xml）：

。。。
com.project




问题：

build [MVN plugins, third party dependency management]:5.1
   NRW Utils:6.0.0.0-beta12-SNAPSHOT
      server-utils:6.0.0.0-beta12-SNAPSHOT
      ... 
   CMW Root:6.0.0.0-beta12-SNAPSHOT
      cmw-webapp:6.0.0.0-beta12-SNAPSHOT
      cmw-core [dependencies on NRW Utils]:6.0.0.0-beta12-SNAPSHOT
      ...
   NRW Root :6.0.0.0-beta12-SNAPSHOT
      nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-beta12-SNAPSHOT
      ...

build [MVN plugins, third party dependency management]:5.1
   nrw-version-management:6.0.0.0-beta-SNAPSHOT
      [contains properties defining latest versions of each collective module]   
      NRW Utils:6.0.0.0-NU-beta4-SNAPSHOT
         server-utils:6.0.0.0-NU-beta4-SNAPSHOT
         ... 
      CMW Root:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-webapp:6.0.0.0-CMW-beta12-SNAPSHOT
         cmw-core [dependencies on NRW Utils]:6.0.0.0-CMW-beta12-SNAPSHOT
         ...
      NRW Root :6.0.0.0-NRW-beta9-SNAPSHOT
         nrw-webapp [depends on NRW Utils & CMW Root modules]:6.0.0.0-NRW-beta9-SNAPSHOT
         ... 


我可以忽略这个警告吗？一些帖子建议使用属性指定POM的父版本是可以接受的
这是常规方法吗？还是有缺陷
是否有更好的解决方案来解决这个不断增长的项目的重组问题

提前感谢。
为所有子模块提供单一版本的好处是简单，这一好处不应低估

如果您真的想依赖同一层次结构中不同版本的模块，那么您应该多次扪心自问。正如您所指出的，发布变得很麻烦

通过使用单一版本以标准化的方式处理关系，并在成功构建后部署到本地回购，您应该能够按照预期的方式享受依赖关系管理

如果您重组了项目，使其符合发布插件的约定，那么发布将变得轻而易举
 我觉得在这个阶段，在整个项目中坚持一个版本是不可行的，因为构建过程现在需要很长时间（前几天7小时后失败了！！）

然而，下面的两个链接并不能完全回答我的问题，但已经达到了目的：




正如尼科·埃基托（nico_ekito）在其中一条评论中所说，在我看来，你现在正陷入“依赖管理噩梦”。根据你的情况。。。管理子模块的不同版本（以及不同的代码稳定性）不就是这些子模块不再是大项目的一部分的症状吗

我的意思是，作为人类，我们可以清楚地表明，这些模块是全局的一部分，是解决问题的整个方法。当您发现您的实用程序类在大范围之外没有用处时，这是很常见的。但是，从Maven的角度来看，我认为您实际上是在处理不同的项目，而不是一个大项目的模块

因此，也许有必要在不同的结构中分离代码库，只需从实际需要的模块中引用实用程序JAR，只需使用稳定的构建，而不是“依赖关系的最后版本”。如果使用稳定的构建，这是不可行的，因为即使该依赖项的代码非常稳定，但它在其他模块的代码不断变化的同时，Maven提供的解决方案是使用快照

我认为，将代码库分解为单独的项目时，您会发现一些好处：


这样Maven就不会在不需要的时候触发那些实用程序模块中的构建
如果你能找到一种方法，只为依赖项使用稳定的版本，你将避免很多麻烦
您还可以打破团队，让那些只使用实用程序jar的团队在使用依赖项的团队的“需求不足的基础上”这样做
如果这些实用程序足够抽象或可重用，那么您可能会在某一天发现另一个项目也可以使用它们，而无需从更大的项目中引用子模块

互联网上有很多关于这种方式（和其他事情）的讨论，很多人抱怨你正面临同样的问题。在我个人看来，Maven是一个很棒的工具，旨在为我们在开始新项目时节省大量时间，但有时会有点麻烦。我开始研究其他类似的工具，但现在更改构建工具可能是更糟糕的事情。仅仅考虑一下打破代码基础的想法，有时我们可以通过一点“项目管理”（在这种情况下是“项目组合管理”）来解决“软件问题”。
谢谢您的意见。我们改变单一版本的原因是，如果没有这个约束，那么将构建分解为“bitesize”块会容易得多，并增加了简单性的额外好处；如果一个模块有更新，我们现在不需要再次构建所有内容。有没有更多的想法/方法来解决这个问题？谢谢。通过共享工件的回购，您可以获得bitesize块。诚然，当您更新版本号时，您必须构建整个项目，但是在更新版本号之后，您只能在有任何开发的地方构建和部署模块/奥斯卡-但是我们已经在为构建的工件使用存储库了。把建筑留在一个