Maven 4 rejects property-interpolated module paths that Maven 3 accepted

[gnodet]

Summary

Maven 4 fails to build multi-module projects that use property expressions in <module> elements when the resulting directory path doesn't exist at POM parsing time. Maven 3 tolerated this pattern (likely by deferring module path resolution or by silently skipping non-existent modules in some configurations).

This affects projects that use Maven profiles to select which submodules to include based on a property value (e.g., Spark or Scala version).

Affected projects (from Maven 4 compatibility testing)

amoro

<module>v${spark.major.version}/amoro-mixed-spark-${spark.major.version}</module>

Error:

Child subproject v${spark.major.version}/amoro-mixed-spark-${spark.major.version} of 
  .../amoro-format-mixed/amoro-mixed-spark does not exist

sedona

<module>spark-${spark.compat.version}</module>

Error:

Child subproject spark-${spark.compat.version} of .../spark does not exist

Analysis

These projects use a pattern where:

1. A property like spark.major.version is set by profile activation
2. The <module> element uses the property to point to a version-specific subdirectory
3. When no profile is active (default build), the property is unset and the path doesn't exist

In Maven 3, this was tolerated. Maven 4 validates module paths strictly during POM parsing before profile activation can set the property value.

Questions

• Is this intentional strictness in Maven 4 POM validation?
• Should mvnup detect and warn about this pattern, even if it can't auto-fix it?
• Could Maven 4 defer module path validation until after property interpolation from profiles?