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).

Other build tools don't suffer from this issue: their build format is kept internal and a POM is produced only while publishing artifacts to Maven repositories, with information just for artifacts consumers but no build instruction.

Maven could apply same strategy: generate a consumer-only POM when publishing artifacts to a repository, with minimal information. The original POM is then called "build" POM since it contains instructions to build the artifact and the generated simplified POM is called "consumer" POM since it's intended for artifact consumers. Once this is done, we can have new build POM versions, which will require newer Maven versions to build, while consumer POM remains compatible with classical POM v4: the only requirement is to be able to generate a consumer POM (a simplified POM v4) from the original build POM used during build: flatten-maven-plugin has already proven that generating a simplified POM from the original POM and publishing it to Maven repository is feasible.

Special case: parent POMs (packaging=pom)

Parent POMs (which are POMs with "pom" packaging) don't really have any meaning as consumer POM: there is no dependency artifact to get from them.

They are useful only as build POMs. Moreover, they are required in Maven repositories to be used either as parent POM or as dependencyManagement import (dependency scope="import" at build time).

Then non-pom-packaging POMs will be published in Maven repositories as consumer POM (v4) but pom-packaging POMs will be published in Maven repositories as build POM only (eventually using new version/format): this use case won't cause issues.

POM File name

Consumer POM file name does not really have a meaning, but if it had, it would remaing as pom.xml.

Build POM file name, while updating POM format, could be changed to something like build.xml, build.pom, or even build.json or build.yaml.

Consumer POM fields

First step is to define which fields from POM v4 we want to keep in consumer POM: removed, kept because required, kept by choice (could be removed if we decide), keep only a part of content

field	status for consumer	comment
<modelVersion/>		not absolutely required, but kept as usual convention
<parent>		content inlined in consumer POM, because we can and it will simplify consumers code rfscholte: should stay ensure the calculation of distances of dependencies. Only the relativePath can be removed, since it point to a File on the local system.
<groupId/> <artifactId/> <version/>
<packaging/>		not absolutely required, since packaging is more a build configuration than something consumers may use
<name/>		necessary because of minimal requirements for central
<description/>		necessary because of minimal requirements for central
<url/>		necessary because of minimal requirements for central
<inceptionYear/>
<organization>
<licenses>		necessary because of minimal requirements for central
<developers>		necessary because of minimal requirements for central
<contributors>		rfscholte: should stay. If people want to remove it, they should use flatten-maven-plugin
<mailingLists>
<prerequisites>		used for plugins, to define runtime Maven version prerequisite
<modules/>		rfscholte: points to a File on the local system, hence can always be removed.
<scm>		necessary because of minimal requirements for central
<issueManagement>
<ciManagement>
<distributionManagement>		keep downloadUrl field only rfscholte: not up to us. Is people want to remove it, they should use flatten-maven-plugin
<properties>		values inlined in consumer POM rfscholte: all dependency-related segments should stay, which means properties too because they can be used as part of the dependency
<dependencyManagement>		rfscholte: all dependency-related segments should stay
<dependencies>	without system scope	system scoped dependencies removed in consumer POM rfscholte: all dependency-related segments should stay, if we allow system-scope at build-time, it must also be consumable.
<repositories>		need to check if repositories configured in dependencies are used during resolution rfscholte: all dependency-related segments should stay
<pluginRepositories>
<build>		this is where the addition of new configuration to enhance Maven build features will be the most useful
<reports/>		let's remove this old Maven 1 compatibility field...
<reporting>
<profiles>
<id/>
<activation>		keep JDK and OS activation only? removing other activations, which are build time. Same as flatten-maven-plugin feature
<dependencies>
<build>     <modules/>     <distributionManagement>     <properties>     <dependencyManagement>     <repositories>     <pluginRepositories>     <reports/>     <reporting>		since removed from base model all dependency-related segments should stay