Needed infrastructure for evolving the model

[gnodet]

The overal goal of this PR is to propose a way to make room for the POM model to evolve in the future. The idea is not to discuss particular evolutions of the model, but only to provide guidelines and provide the needed features for the evolution to happen. This proposal is based on various previous discussions, mainly the Build vs Consumer POM discussion.

The main driver is to allow maven to evolve and the main constraint is to not break the ecosystem, especially Maven Central.

Currently, Maven 4 provides a consumer POM which is uploaded by default instead of the exact POM located on the file system. The differences are minor: remove the <modules> element, the <parent>/<relativePath> element, and the root attribute which has been recently added. The discussion that happened years ago was not completely settled with respect to what exactly should be removed.

My proposal is thus the following: prune the consumer POM from all build related elements and upload it instead of the current pom. That's what the build/consumer features already does, so it's just about removing more stuff and flattening the hierarchy. This will help consumers and will effectively speed up the process on the long term (as the process of computing the whole hierarchy, interpolating, etc... can be quite time consuming). In order to keep the whole information available, I thus propose to always upload the build POM (well, the current consumer POM) as the build pom with a build classifier, let's call it normalized build pom. This is for non-pom-packaged artifacts.

For pom-packaged artifacts, there are two different use cases: either the POM is used as a parent or imported as a BOM. Both use cases are different, and I think the BOM use case is on the consumer side, rather than the build side. So I propose to add a new bom packaging that could be used instead of using pom+import scope. The bom packaging is translated back to pom in the consumer POM before being uploaded for compatibility with Maven 3.x. The point is to make the difference at build time between a BOM and a POM, so that the BOM can be uploaded with a consumer POM, while the POM used as a parent cannot as it cannot afford to loose any information.
So two sub cases: BOM will be uploaded like non-pom-packaged artifacts above (i.e. with flattened consumer POM + build POM). Parent POMs need to be uploaded with the build POM only.

Here comes the question about opening the POM model for change. We're mostly talking about the build side of things. The real problem mainly affects pom-packaged artifacts used as parents, as those need to be uploaded, while non-pom-packaged artifacts will have their main pom translated into a consumer POM at installation/deployment time. So this proposal would allow the use of a newer POM (i.e. 4.x or 5.x, that's irrelevant) in place of the main pom in central for pom-packaged artifacts used as parents. That means that if a project inherit from a newer POM, it will have to be built with a newer maven version, as older maven versions will reject any unknown attribute or element. The namespace change could also break some tools. This really only affect pom-packaged artifacts, but in order to further mitigate the disruption, I propose that by default the build-pom is downgraded to the lowest compatible namespace at install/deploy time : i.e. if you write a pom v5, but do not use any new feature, maven should change the namespace version down to 4.0.0. This could be turned off by using a new attribute on the POM.

Related to the actual POM5 content and syntax, it has been envisioned to use attributes instead of elements. This does not really affect the model per se, and that's mostly about syntax. The model will obviously have to evolve to support new additions, however the syntax can be kept by default on the build side. This can be easily implemented using ideas borrowed from the polyglot extension. This would provide support for an enhanced xml syntax and for an alternative yaml/hocon/json/whatever syntax (see the following poc). For simplicity, I think we should keep the current xml syntax the way it is and use a different schema version. The alternative xml syntax could use a different namespace.

This PR currently provides:

• new BOM packaging to clearly distinguish pom-packaged modules used as parents or BOMs
• flattened consumer pom installed/uploaded as the main pom for non-pom-packaged artifacts (so including BOMs) + normalized build pom
• normalized build pom installed/uploaded for pom-packaged artifacts
• translation of bom packaging to a pom package at installation/deploy time
• support writing a pom with a different namespace than 4.0.0
• polyglot SPI to allow plugin in alternative syntax
• identification of minimum model version in use for a given pom (it may be generated from the mdo by associating each field with the version it has been introduced and walking a given object and grabbing the maximum used version for all non null fields)

Missing:

• new tests to cover those features (the build/consumer specific tests have been enhanced to cover the new stuff, but that's all)

PR for ITs: apache/maven-integration-testing#272

[gnodet]

Split in smaller PRs.