...

The consumer-only POM will also be easier to explain and document consumer features, without being disturbed by build content. And it's a first step towards complete separation of build and consumer features that comes with Project Dependency Trees schema proposal.

From File to Effective POM

Up until Maven 3.6.3 the ModelBuilder reads the file, resulting in the raw model. To get the effective model, the raw model was cloned (Java) and enriched according to https://maven.apache.org/ref/3.6.3/maven-model-builder/

Since Maven 3.7.0 the ModelBuilder reads the file, resulting in the file model. Next, the file is read again, now using the BuildPomXMLFilter, resulting in another Model. This is merged into the file model, so all linenumber will match the original pom.

For this reason, the ModelValidator interface has a new default method: validateFileModel (yeah Java 8), which can still do most validations of the original validateRawModel. The latter can check the extended result from the BuildPomXMLFilter.

One of the filters is the ReactorDependencyXMLFilter, which can inject the version based on the reactor modules. However, this means that all fileModels must have been read, otherwise this information is not available in the transformContext. The ModelBuilder only reads one file, might include the parent, but doesn't handle the modules, that is done by the ProjectBuilder. 

Special case: parent POMs (packaging=pom)

...

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

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

  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

...