...

• "It is too hard to make a custom template/packaging"
• "This is a one-off project, we will never make another of this type, therefore it doesn't make sense to produce a custom template/packaging" 

...

Changes

This section details the rationale for all the changes to the POM format.

Dual usage

The most important change for the 5.0.0 POM is to split the dual usage:

• The 5.0.0 POM will be used as a declarative description of the build processes of the project. 
• The description of the project artifact dependency graphs will be provided by the Project Dependency Trees schema proposal.

DECISION: The POM is for Building, the Project Dependency Trees is for consumption of artifacts

AFFECTS: 

XML vs custom DSL

The project dependency trees schema will be XML because that is designed to be a machine generated document that is for consumption primarily by machines but needs to remain easily parsable by humans. The choice of XML is dictated by the requirement to enable multiple tools to have a level of forward compatibility and, at this time, the only cross-technology tool that can deliver a mapping mapping is XSLT. For this reason the Project Dependency Trees schema will be an XML format.

As the 5.0.0 POM will only be used by Maven, and as the 5.0.0 POM will require Maven 5.0+ to build, there is no longer a strict requirement to retain the XML format for the 5.0.0 POM.

There are, however, a number of advantages to continuing with the XML based format at least for the 5.x release train of Maven:

• Most editors already have syntax highlighting and completion support for XML, e.g. when closing an element
• A significant number of editors can use the XML schema to provide enhanced completion support, e.g. providing contextual suggestions for elements and attributes
• Familiarity of the existing user base, e.g. the current users of Maven are already used to the XML based-syntax
• Reduces the number of code paths to allow Maven 5.0+ to parse the 4.0.0 POM, e.g. it will significantly aid adoption of Maven 5.0+ if you can build Maven 2/3 projects with Maven 5.0+

The single biggest reason for retaining XML, however, is that we expect the build model will need to evolve. With the Project Dependency Trees schema, we need to provide for backwards compatibility (i.e. newer clients need to be able to parse older schemas) and limited forward compatibility (i.e. older clients need to be able to parse newer schemas). With the POM, we only need to provide for limited backwards compatibility (i.e. newer versions of Maven need to be able to parse a defined range of older schemas) without forwards compatibility (i.e. older versions of Maven will not be able to build newer POM modelVersions). Ideally we want the range of backwards compatibility to reach back as far as the 4.0.0 POM. Retaining XML as a POM format allows for technology such as XSLT to be used to map say a 5.0.0 POM into a 5.3.0 POM which would thus reduce the number of parsers that would be required to be included within Maven (we will still need a custom parser for the 4.0.0 POM, and it is likely that Maven 6.0+ would need custom two parsers one for the 4.0.0 POM and one for the 5.x.y POMs). A custom DSL would force tool vendors to produce syntax parsers for each and every model version.

DECISION: The 5.0.0 POM will be XML

AFFECTS: 

Elements vs Attributes

There seems to be universal agreement to use attributes where possible. The reason for choosing elements in the 4.0.0 was purely a technical limitation of the Modello toolchain at the time.

DECISION: The 5.0.0 POM will use XML attributes for data that cannot have child data. At a minimum the groupId/artifactId/platformId/version/classifier/type information of project/parent/dependencies/plugins/extensions will be defined using attributes.

AFFECTS: 

Customizing build behavior / One-off projects

The term packaging in the 4.0.0 POM is used for two distinct purposes: defining the type of the primary artifact and defining the base template of the build process. The Project Dependency Trees schema removes the concept of a primary artifact by providing the dependency trees of all attached artifacts, thus a single Maven project that produces a .jar, .war and even say a secondary "skinny" .war will have the appropriate dependency trees for each artifact declared in the PDT. This contrasts with the 4.0.0 POM which only defined the dependencies of the primary artifact and relied on build tooling convention to infer what contextual transitive dependencies should be extracted by consumers from the POM.

Thus, in the 5.0.0 POM we only really want to specify the template for the lifecycles and default bindings. Given that the use case for this data is purely as a template, it makes sense to change the name to template.

DECISION: The 5.0.0 POM will use the term template rather than packaging.

AFFECTS: 

One of the requirements that a lot of projects have is cross-cutting inheritance. There is general agreement that mix-ins are the way to achieve this.

DECISION: The 5.0.0 POM will allow for mix-ins

AFFECTS: 

The evidence of the use of Maven shows that there seems to be a significant number of projects that believe themselves to be "one-off" projects that will not benefit from expressing the build logic in a reusable template. We need to provide a way to allow projects to easily change their effective lifecycle and plugin bindings

DECISION: The 5.0.0 POM will provide the ability to define custom lifecycles directly within the POM

AFFECTS: 

DECISION: The 5.0.0 POM will provide the ability to override and completely clear the plugin bindings against individual lifecycles

AFFECTS: 

TODO write this up... I'm just dumping stuff I have done on the mail thread here to make it easier to collaborate:

...