...

The Maven POM format has been stable for several years. It is described by an XML schema (http://maven.apache.org/xsd/maven-4.0.0.xsd^{Image Removed}) that makes no allowance for extension. Thus, tools that read POMs are entitled to expect POMs to follow the schema precisely.

...

However, it's not required that any arbitrary version of Maven be able to correctly build any project. This is the purpose of the /project/prerequisites/maven. An interesting question below is whether there should be a coupling between the POM version and new information in the POM. This is discussed below. 

Basic Design

The fundamental idea of this solution is to add a revision number to the artifact type of a POM. Right now, all POMs are of type ‘pom’. In this design, you can think of ‘pom’ as equivalent to ‘pom4’, and anticipate that the next step is to have new artifacts of type ‘pom5’.

On the surface, this seems simple and insufficient. Some new version of maven emits and consumes ‘pom5’ artifacts, and is thus completely disconnected from previous versions of Maven. That isn’t going to help anyone. Compatibility requires more complexity, as follows:

• Down-conversion is required: It must be possible to derive a ‘pom4’ model from a ‘pom5’ model. While this process will inevitably lose information, the resulting ‘pom4’ model must at least permit a broad range of relatively ordinary projects to build.
• New Maven reads Old Pom: When looking for a POM in a repository, if the ‘pom5’ Maven fails to find a ‘pom5’, it must look for, and consume, a ‘pom4’.
• Publish old for new: Installing or Deploying a ‘pom5’ must, in parallel, install or deploy the corresponding ‘pom4’. Thus, ordinary deployment from the pom5 Maven produces an artifact consumable by old tools.

...

In theory, repository managers, at most, read ‘pom’ artifacts and treat unknown types as opaque. Thus, the design above should work without any initial changes to any repository manager. What if, however, some repository manager refused to cooperate in storing ‘pom5’ artifacts? I hope that this question is completely hypothetical. If it isn’t, we could consider some scheme of encoding ‘pom5’ data in special comments in ‘pom4’ files. This leads rapidly to a mare’s nextnest of complexity, so I hope we don’t have to go there.

...

Adding attributes, when they make sense, is a very effective way to make small additions that are backward-compatible. No sane piece of Java code
is code is going to refuse to process a POM because it sees an unfamiliar attribute. Attributes are simply too common of a mechanism for extension and annotation.

...

Imagine that we define something like <url inherit='false'> to mean 'Don't allow children to inherit this URL.' Perhaps this should implicitly set /project/prerequisites/maven to the version of Maven that first supported this, to avoid incorrect builds with old versions of maven? Except, of course, that this would require a time machine to apply to maven 2.2.1 and before. 

There's a bit of a dilemma in the use of attributes. Many people complain about the sheer verbosity of Maven POMs. Using attributes is often far less verbose. On the other hand, it would be kind of awful if you had to guess whether some bit of information was an attribute or a child element. The inheritance control is a good example of attribute use, because it is specifying a fact about this particular element. Going down the path of, oh, <forkMode v='always'/> to reduce the verbosity is perhaps not a great idea.

Namespaces

Namespaces are a subject of some controversy in the world of XML. The decision of the HTML5 junta to run away with them is a reason to pause before diving into them willy-nilly. Nonetheless, I think that they make some sense in POMs.

...