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

Question

我正在考虑重组一个大型 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
      ...

更改原因：

每个集体模块的大小（即 NRW Utils） 、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
      ...  

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

还值得注意的是，实际上有 5 个不同的“集体模块”（不仅仅是 3 个），所有模块都使用不同的版本（通过唯一的键来区分）构建，这就是为什么我认为最好有一个集中的地方版本，而不是 5 个不同 POM 中的重复属性。

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

建议的依赖版本管理解决方案：

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-version-management (pom.xml)：

...
<parent>
    <groupId>com.project</groupId>
    <artifactId>build</artifactId>
    <version>5.1</version>
</parent>
<groupId>com.project</groupId>
<artifactId>nrw-versions-manager</artifactId>
<version>6.0.0.0-beta-SNAPSHOT</version>
<name>Version Maven Properties</name>
<description>A centralised place for all module property versions</description>
<packaging>pom</packaging>
<properties>
    <nrw.utilities.version>6.0.0.0-NU-beta4-SNAPSHOT</nrw.utilities.version>
    <nrw.cmw.version>6.0.0.0-CMW-beta12-SNAPSHOT</nrw.cmw.version>
    <nrw.version>6.0.0.0-NRW-beta9-SNAPSHOT</nrw.version>
</properties>
...

CMW Root (pom.xml)：

...
<parent>
    <groupId>com.project</groupId>
    <artifactId>nrw-versions-manager</artifactId>
    <version>${nrw.core.version}</version>
    ...
</parent>
<groupId>com.project</groupId>
<artifactId>CMW-root</artifactId>
<version>6.0.0.0-CMW-beta12-SNAPSHOT</version>
<packaging>pom</packaging>
<dependencyManagement>
    <dependencies>
        ...
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>server-utils</artifactId>
            <version>${nrw.utilities.version}</version>
        </dependency>
        ...
</dependencyManagement>
<profiles>
    <profile>
        <id>all</id>
        <modules>
            <module>cmw-webapp</module>
            <module>cmw-core</module>
            ...
        </modules>
    </profile>
    ...
</profiles>
...

注意然后，通过命令行参数（或默认属性值）将属性 ${nrw.core.version} 设置为 6.3.0.0-beta-SNAPSHOT 以进行快照构建。

可能的发布过程（对于 6.0.0.0）：

1. 构建 5.1 构建模块（如果尚未构建）
2. 构建 nrw-version-management 6.0.0.0（以避免快照依赖性 - 但尚未更改任何属性）
3. 构建北威州公用事业 6.0.0.0-NU cmd 参数：-Dnrw.core.version=6.0.0.0
4. 构建 CMW 根 6.0.0.0-CMW cmd 参数：-Dnrw.core.version=6.0.0.0 -Dnrw.utilities.version=6.0.0.0-NU
5. 构建 NRW 根 6.0.0.0-NRW cmd args：-Dnrw.core.version=6.0.0.0 -Dnrw.utilities.version=6.0.0.0-NU -Dnrw.cmw.version=6.0.0.0-CMW
6. 为存储库重新构建 nrw-version-management 6.0.0.0 cmd 参数：-Dnrw.core.version=6.0.0.0 -Dnrw.utilities.version=6.0.0.0-NU -Dnrw.cmw.version=6.0.0.0-CMW
7. 构建 nrw-版本-管理 6.1.0.0-beta-SNAPSHOT使用新的开发版本并更新 POM 文件

问题：

构建过程似乎很冗长，尤其是相关到 nrw 版本管理模块。 另外，我开始看到这个警告：

'version'包含一个表达式，但应该是一个常量

，经过一些调查，我现在明白在设置版本时（指定父 POM 时）不建议使用表达式：

• 关于在 Maven 3 中使用 project.parent.version 作为模块版本的警告< /一>
• <一href="https://stackoverflow.com/questions/3684664/maven-property-substitution-not-done-for-project-version-tag-of-pom/">Maven：未对 /project/version 进行属性替换pom 的标签？
• http://maven.40175.n5.nabble.com/Pom-Parent-Version-Properties-td124576.html

问题：

• 我可以忽略吗这个警告？一些帖子开始表明使用属性指定父 POM 版本可能是可以接受的。
• 这种一般方法是传统的吗？还是有缺陷？
• 是否有更好的解决方案来解决这个不断增长的项目的重组问题？

提前致谢。

Answer 1

所有子模块都采用单一版本的好处是简单，这一好处不应被低估。

您确实应该多次问自己是否真的想依赖同一层次结构中不同版本的模块。正如您所指出的，发布变得很麻烦。

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

如果您重组项目以使其遵守发布插件的约定，那么发布就会变得轻而易举。

Answer 2

正如 nico_ekito 在其中一条评论中所述，在我看来，您现在正陷入“依赖管理噩梦”。根据您的场景......管理子模块的不同版本（以及不同的代码稳定性）的事实难道不是这些子模块不再是大项目的一部分的症状吗？

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

因此，也许值得将不同结构的代码库分开，只简单地从实际需要它的模块中引用实用程序 jar，并使用稳定的构建而不是“该依赖项的最后版本”。如果使用稳定的构建，这是不可行的，因为即使该依赖项的代码非常稳定，但它与其他模块的代码同时不断变化，那么 Maven 为您提供的解决方案就是使用 SNAPSHOTS。

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

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

互联网上有很多关于这种方式的讨论 Maven 处理依赖项（和其他事情），很多人抱怨你面临的同样问题。在我看来，Maven 是一个很棒的工具，旨在为我们在启动新项目时节省大量时间，但有时它可能会有点麻烦。我开始考虑其他工具，例如 Gradle 但现在更改构建工具可能是更糟糕的事情。只要考虑一下打破代码库的想法，有时我们只需一点“项目管理”（或在本例中为“项目组合管理”）就可以解决“软件问题”。

Answer 3

我认为在这个阶段在整个项目中坚持使用单一版本是不可行的，因为构建过程现在需要很长时间（前几天它在 7 小时后失败了！！）。

但是，下面的两个链接并没有完全回答我的问题，但已经解决了：

• 如何在多个maven项目之间共享公共属性？
• 我如何告诉 Maven使用最新版本的依赖项？