本文旨在解决maven多模块项目中子项目需要独立版本时，因依赖解析错误导致的构建失败问题。核心在于明确区分子项目自身版本与父项目版本。通过在子项目中对来自父项目的依赖明确使用${project.parent.version}而非默认的${project.version}，可确保依赖正确解析，从而实现子项目版本的独立管理。
Maven多模块项目中的版本管理策略
在Maven多模块项目中，子项目通常会继承父项目的版本。这是Maven约定优于配置原则的体现，简化了多模块项目的版本同步。然而，在某些特定的业务场景下，例如子项目有独立的发布周期、版本演进路线或需要与父项目进行非同步更新时，我们可能需要为子项目指定一个与父项目不同的版本。Maven允许子项目通过在其pom.xml中显式定义
以下是一个子项目显式指定其独立版本的示例：
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>io.parent-test</groupId>
<artifactId>io.parent-test</artifactId>
<version>0.9.1-SNAPSHOT</version>
<relativePath></relativePath>
</parent>
<artifactId>test-project-converter</artifactId>
<version>0.9.2-SNAPSHOT</version> <!-- 子项目独立版本 -->
<name>test-project</name>
<description>Test Project</description>上述配置中，父项目的版本为0.9.1-SNAPSHOT，而子项目test-project-converter的版本被独立设置为0.9.2-SNAPSHOT。这种做法本身是完全有效的，Maven能够识别并处理子项目的独立版本。
依赖解析的常见陷阱：${project.version}的误用
当子项目拥有独立版本时，一个常见的错误是，子项目中定义的某些依赖仍然使用${project.version}来指定其版本，而这些依赖实际上是期望从父项目中继承或由父项目管理的。
考虑一个依赖项在子项目中被这样定义：
<dependency>
<groupId>io.parent-dep</groupId>
<artifactId>parent-dev</artifactId>
<version>${project.version}</version>
</dependency>在父子版本一致的情况下，${project.version}会正确解析为父项目的版本。然而，一旦子项目显式设置了与父项目不同的版本（如0.9.2-SNAPSHOT），那么在子项目的上下文中，${project.version}将解析为子项目自身的版本（即0.9.2-SNAPSHOT）。如果io.parent-dep:parent-dev这个依赖实际上是由父项目在0.9.1-SNAPSHOT版本下提供或管理的，那么Maven将尝试寻找io.parent-dep:parent-dev:0.9.2-SNAPSHOT。由于父项目并未提供此版本的依赖，或者该版本不存在于任何可用的仓库中，最终将导致Cannot resolve错误，从而阻止项目成功构建。
解决方案：明确引用父项目版本
为了解决上述依赖解析错误，当子项目中的依赖是期望从父项目继承或由父项目提供时，我们应该明确使用Maven内置的属性${project.parent.version}来引用父项目的版本，而不是${project.version}。
${project.parent.version}属性总是指向当前模块的父项目的版本。通过这种方式，即使子项目有独立的版本，它也可以确保依赖正确地解析到父项目所提供的版本，从而避免版本不匹配的问题。
以下是修正后的子项目pom.xml配置示例：
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>io.parent-test</groupId>
<artifactId>io.parent-test</artifactId>
<version>0.9.1-SNAPSHOT</version>
<relativePath></relativePath>
</parent>
<artifactId>test-project-converter</artifactId>
<version>0.9.2-SNAPSHOT</version> <!-- 子项目独立版本 -->
<name>test-project</name>
<description>Test Project</description>
<dependencies>
<dependency>
<groupId>io.parent-dep</groupId>
<artifactId>parent-dev</artifactId>
<!-- 明确引用父项目的版本，确保依赖正确解析 -->
<version>${project.parent.version}</version>
</dependency>
<!-- 其他依赖 -->
</dependencies>通过将parent-dev依赖的版本从${project.version}修改为${project.parent.version}，Maven在解析该依赖时会使用父项目0.9.1-SNAPSHOT的版本，而不是子项目0.9.2-SNAPSHOT的版本，从而成功定位并引入正确的依赖。
注意事项与最佳实践
-
何时使用${project.version} vs. ${project.parent.version}：
- ${project.version}：当依赖项的版本确实与当前子项目的版本生命周期一致，或者该依赖是子项目自身发布的一部分时使用。例如，如果子项目A依赖于子项目B，且B的版本应该与A保持同步，则可以使用${project.version}（假设A和B都继承了相同的父版本，或者B的版本也设置为${project.version}）。
- ${project.parent.version}：当依赖项的版本是由父项目定义、管理或期望与父项目版本保持一致时使用。这对于父项目提供的公共库、工具模块或由父项目集中管理的第三方库版本尤其重要。
-
dependencyManagement的利用： 为了更好地管理多模块项目的依赖版本，强烈建议在父项目的pom.xml中使用
块。这允许在父项目中集中声明所有依赖的版本，子项目在引用这些依赖时无需指定版本，Maven会自动从父项目的dependencyManagement中获取。这种方式是实现依赖版本一致性与子项目版本独立性的最佳实践。 父项目 pom.xml 示例:
<project> <modelVersion>4.0.0</modelVersion> <groupId>io.parent-test</groupId> <artifactId>io.parent-test</artifactId> <version>0.9.1-SNAPSHOT</version> <packaging>pom</packaging> <!-- 父项目通常是pom类型 --> <dependencyManagement> <dependencies> <dependency> <groupId>io.parent-dep</groupId> <artifactId>parent-dev</artifactId> <version>${project.version}</version> <!-- 这里指父项目自身的版本 --> </dependency> <!-- 其他受父项目管理的依赖 --> </dependencies> </dependencyManagement> <modules> <module>test-project-converter</module> </modules> </project>子项目 pom.xml 示例 (当父项目使用dependencyManagement时):
<modelVersion>4.0.0</modelVersion> <parent> <groupId>io.parent-test</groupId> <artifactId>io.parent-test</artifactId> <version>0.9.1-SNAPSHOT</version> <relativePath>../pom.xml</relativePath> <!-- 确保相对路径正确 --> </parent> <artifactId>test-project-converter</artifactId> <version>0.9.2-SNAPSHOT</version> <!-- 子项目独立版本 --> <name>test-project</name> <description>Test Project</description> <dependencies> <dependency> <groupId>io.parent-dep</groupId> <artifactId>parent-dev</artifactId> <!-- 版本由父项目的dependencyManagement提供，无需在此指定 --> <!-- Maven会自动从父项目中获取0.9.1-SNAPSHOT版本 --> </dependency> <!-- 其他依赖 --> </dependencies>在这种情况下，子项目即使有独立的版本，parent-dev依赖的版本也会正确地从父项目的dependencyManagement中获取，而无需在子项目中显式使用${project.parent.version}。这是更推荐的做法，因为它提供了更清晰的依赖版本管理机制。
总结
在Maven多模块项目中，为子项目设置独立版本是完全可行的，但需要特别注意依赖的解析逻辑。当子项目依赖的模块版本应与父项目版本保持一致时，务必使用${project.parent.version}来明确指定，以避免因${project.version}解析到子项目自身版本而导致的依赖找不到问题。更进一步，结合dependencyManagement机制，可以实现更优雅、高效的多模块项目版本和依赖管理，既保证了依赖版本的一致性，又赋予了子项目版本独立的灵活性。
