...

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

   looks for general purpose mix-ins

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

   looks for an explicit pluginManagement scoped mix-in

Proposal

Existing model

The existing 4.0.0 model POM has the following high-level structure:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
 
  <!-- The Basics -->
  <groupId>...</groupId>
  <artifactId>...</artifactId>
  <version>...</version>
  <packaging>...</packaging>
  <dependencies>...</dependencies>
  <parent>...</parent>
  <dependencyManagement>...</dependencyManagement>
  <modules>...</modules>
  <properties>...</properties>
 
  <!-- Build Settings -->
  <build>...</build>
  <reporting>...</reporting>
 
  <!-- More Project Information -->
  <name>...</name>
  <description>...</description>
  <url>...</url>
  <inceptionYear>...</inceptionYear>
  <licenses>...</licenses>
  <organization>...</organization>
  <developers>...</developers>
  <contributors>...</contributors>
 
  <!-- Environment Settings -->
  <issueManagement>...</issueManagement>
  <ciManagement>...</ciManagement>
  <mailingLists>...</mailingLists>
  <scm>...</scm>
  <prerequisites>...</prerequisites>
  <repositories>...</repositories>
  <pluginRepositories>...</pluginRepositories>
  <distributionManagement>...</distributionManagement>
  <profiles>...</profiles>
</project>

The major critiques of the existing model are:

• Overly verbose and repetitive - the main pain point is that the groupId, artifactId, etc are not specified as attributes
• "I hate XML" - our current thinking is that this is really just a catch-all complaint from people who:
  • Don't like the schema / feel the schema is overly verbose
  • Want to produce an imperative build from a declarative build tool
  • Are tolling for fun and profit
• Poorly specified dependency graph resolution
• "Magic" inheritance - it can be difficult to determine how inheritance will affect the build.

The other issue with the existing model is that it is being used for two distinct purposes and as such finds it difficult to be a master of both:

• The 4.0.0 POM serves as a declarative description of the build process for a project
• The 4.0.0 POM serves as a description of the project dependency graph.

The vision of the 4.0.0 POM was that all projects would be cut from a series of standard templates (a.k.a. packaging):

• Each template would define the appropriate lifecycles and phases of those lifecycles (hopefully most templates/packagings would be sufficiently served by the three default lifecycles: default, clean and site) and each template/packaging would define the plugin bindings against the lifecycle phases. 
• Where a project needed a customized build process, the build engineer would initially explore how to develop the build process by customizing the bindings of an existing template/packaging.
• Once the build engineer had determined the correct generic process for building this type of project, the build engineer would then solidify this build process into a custom template/packaging.

In this vision, almost all 4.0.0 POMs should basically consist of the following structure:

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent> <!-- most projects should inherit from a parent pom of some sort --> 
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <version>...</version>
    <relativePath/>
  </parent>
  <artifactId>...</artifactId> <!-- most projects should inherit the parent's groupId -->
  <version>...</version>
  <packaging><!-- THIS IS THE IMPORTANT BIT--></packaging>
  <dependencies>
    ... <!-- Here is the project dependencies -->
  </dependencies>
  <build> <!-- no custom plugin configuration or bindings -->
    <extensions> <!-- this is only needed if not inherited from the parent -->
      <extension>
        <groupId>...</groupId>
        <artifactId>...</artifactId>
        <version>...</version>
      </extension>
    </extensions>
  </build>
</project>

In other words, when using the 4.0.0 POM in accordance with its initial vision, there should be at most 25 lines of boilerplate above the specification of the project dependencies and in the ideal case that boilerplate can be reduced to ~14 lines which specify:

• the versions of Maven which the POM is compatible with (the modelVersion)
• the parent to inherit from (3 lines of information due to the use of XML elements instead of attributes)
• the identity of this project (2 lines of information if inheriting the groupId from the parent)
• the template/packaging that this project is built with

When we inspect real world POMs however, we see that this pattern is almost never followed. Instead of producing custom templates/packaging most projects instead just fight with a standard template/packaging. The end result of this kind of fighting is POMs that run into the 10,000+ LOC levels with many plugin bindings and overloading of an existing lifecycle binding and profiles used to enable additional side-build processes. The reasons cited for these long POMs include:

• "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" 

Proposal

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.

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  

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

...