...

Rationale

Maven is stuck on POM v4 for a long time now, because changing the POM version and publishing artifacts on Maven Central with this new model would break consumers using either older Maven versions or other build tools (that use POM v4 as a compatibility format).

...

• project.version from sub-modules can be inferred from disk: no need to write in build-POM, the value can be added when generating consumer POM
• project.version containing properties can be transformed to exact values in consumer-POM, particularly in CI-friendly case
• project.dependency.version can be skipped in build POM when it's a reactor-internal reference

First Step: Maven 3.7.0 build POM

Jira
server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key MNG-6656

As a first step to test consequences of differentiating build from consumer POM, a choice on a few differences has been made:

• removal of project.version in build POM: in case the <parent/> is located at its relativePath (default: ../pom.xml), the version can be removed from build POM. groupId and artifactId are still required to ensure it is being matched with the right parent.

• removal of dependencies versions in build POM: dependencies that are part of the reactor don't need a version anymore

• cifriendly placeholders in versions (${sha1}, ${revision}, ${changelist}) in build POM will be resolved in consumer POM

• <modules> from <project> will be removed from consumer POM

• <relativePath> from <parent> will be removed from consumer POM

Future Steps

We'll define precisely in the future if other fields should be removed from the consumer POM, or if other improvements of build POM can be done without adding new fields