Maven 4 dependency version validation fails for CI-friendly ${revision} projects with inherited dependency versions

[gnodet]

Summary

Maven 4 fails to build projects that use CI-friendly versions (${revision}) when child modules have dependencies without explicit <version> elements that rely on dependencyManagement inherited from the parent. Maven 4 raises errors like 'dependencies.dependency.version' is missing during POM validation, before the dependency management inheritance has been fully resolved.

Affected projects (from Maven 4 compatibility testing)

incubator-seata

Uses ${revision} CI-friendly versioning. The seata-all module has ~20+ dependencies without explicit versions (spring-context, protostuff-core, grpc-netty, postgresql, jackson-datatype-jsr310, kryo, junit-jupiter, mockito-core, etc.) that are managed by the parent's dependencyManagement.

[ERROR] 'dependencies.dependency.version' for groupId='org.springframework', artifactId='spring-context', 
  type='jar' is missing. @ org.apache.seata:seata-all:${revision}, .../project/all/pom.xml, line 359, column 9
[ERROR] 'dependencies.dependency.version' for groupId='io.protostuff', artifactId='protostuff-core', 
  type='jar' is missing. @ org.apache.seata:seata-all:${revision}, .../project/all/pom.xml, line 563, column 9

(20+ similar errors for different dependencies)

Note: mvnup apply ran successfully on this project and modified many POMs, but did not fix these missing version errors — it lacks a rule for this pattern.

Analysis

The pattern is:

1. Parent POM defines <version>${revision}</version> and has comprehensive <dependencyManagement>
2. Child modules declare <dependency> without <version>, relying on inheritance from parent's dependencyManagement
3. Maven 3 resolved this correctly
4. Maven 4 validates dependency completeness before fully resolving the dependencyManagement inheritance chain

This may be related to the ${revision} CI-friendly version handling, where the parent version contains an uninterpolated property — Maven 4 might fail to load the parent's dependencyManagement when the parent's own version is ${revision}.

Questions

• Is this a POM validation ordering issue (validation before dependencyManagement inheritance)?
• Is this related to how ${revision} affects parent POM resolution?
• Should mvnup add explicit versions to dependencies that rely on inherited dependencyManagement?