Status

This RFC is currently in the DRAFT state. Nothing in this RFC has been agreed or confirmed.

Contents

Introduction

The next generation Project Object Model to be used by Maven 5.0+

Background

Maven uses the Project Object Model as a descriptor for the declarative build requirements of a project.

• Maven 1.x used a model which contained a <modelVersion>3.0.0</modelVersion> element as an immediate child of the root. 
• Maven 2.x / 3.x has used a <modelVersion>4.0.0</modelVersion> element. 

Due to the way Maven has been implemented, the current release versions will consider any modelVersion other than the one that they target as invalid and will fail to parse the model.

For build time concerns, this is not that major a concern, and in fact may be desirable behaviour, e.g. I should not be able to build a Maven 2.x / 3.x project with Maven 1.x.

Where the modelVersion becomes a constraint, however, is when it comes to transitive dependency resolution. The Maven Central repository has grown in popularity, and now the consumers of the information in central are no longer only Apache Maven. There are other build tools that parse the POM to extract dependency information, e.g. Apache Buildr, Gradle, Apache Ivy, sbt, etc. As these build tools are not under the control of the Apache Maven project, we risk breaking their ability to parse the POM as a unit of dependency expression if we modify the pom schema or model version.

While we could change the schema if we "forked" the central repository, the experience from the previous reposotory fork (for the Maven 1.x / Model Version 3.0.0 to Maven 2.x / Model Version 4.0.0 transition) was traumatic and a repeat is generally considered to be a Bad Plan™.

The result of all this is that the Apache Maven project has been unable to evolve our POM to reflect the new needs.

The current plan for a Path Forward™ uses three legs:

1. We keep deploying modelVersion 4.0.0 poms to the repository as a best effort expression of the dependency information of artifacts such that legacy clients can continue to consume artifacts deployed with non-legacy clients.
2. We deploy a dependency-only model using a defined contract for forwards compatibility (to allow for future evolution) using a different file extension (see Project Dependency Trees schema)
3. The POM then becomes a build-time only concern and does not need to be deployed to the repository - except for those cases where the pom may be used as either a parent or a mix-in

This page will represent (TODO replace "will represent" with "represents" when near finalised) the specification for the next modelVersion of the POM to be used by Maven.

Classification of change requests

There are currently 

New content to include in the POM

The following issues look to add content for documentational purposes. This content would be consumed both by developers reading the POM "by hand" as well as by more automated tooling such as the Maven Site generation

• Unable to render Jira issues macro, execution error.  looks for the ability to include links to the coding standards and formatting rules that a project uses. 
• Unable to render Jira issues macro, execution error.  looks for the ability to document IRC channels. More generally, if IRC channels are documented, other kinds of instant messaging and social media channels should be documented.
• Unable to render Jira issues macro, execution error.  looks for the ability to document quality management services (such as sonar) similar to how we allow defining continuous integration services (such as Jenkins)

The following issues look to add content to assist using maven on a specific project

• Unable to render Jira issues macro, execution error.  looks for the ability to define information to display to the user if they invoke maven with no goals specified and no default goal defined in the POM. Additionally the message should be customizable per profile
• Unable to render Jira issues macro, execution error.  looks for a way to validate plugin configuration. An interesting thought experiment would be to allow a POM to be parameterized with some parameters requiring input at invocation time such that Maven would always ask for that parameter (using a custom prompt) if it wasn't supplied.

The following issues TODO I STOPPED HERE 

• Unable to render Jira issues macro, execution error.
• Unable to render Jira issues macro, execution error.
• Unable to render Jira issues macro, execution error.
• Unable to render Jira issues macro, execution error.
• Unable to render Jira issues macro, execution error.
• Unable to render Jira issues macro, execution error. Open question do we want properties? and if we do, what interpolation rules would apply... how would parent, mix-in, platform, profiles etc take effect...
• Unable to render Jira issues macro, execution error. WONT FIX I do not see the value in splitting content out of the pom... that way leads to profiles.xml which was madness
• Unable to render Jira issues macro, execution error. WONT FIX I do not see the value in splitting content out of the pom... that way leads to profiles.xml which was madness

Overview

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

<project modelVersion="5.0.0" [groupId="..."] artifactId="..." [version="..."] packaging="...">
  [<parent groupId="..." artifactId="..." [version="..."] [relativePath="...']/>

  [<mixin groupId="..." artifactId="..." [version="..."]/>]
  [<mixin groupId="..." artifactId="..." [version="..."]/>]
  ...
  [<mixin groupId="..." artifactId="..." [version="..."]/>]

  [<lifecycle id="..." mode="override|inherit">
    <phase id="..." [after="..." | before="..."]/>
    <phase id="..." [after="..." | before="..."]/>
    ...
    <phase id="..." [after="..." | before="..."]/>

  </lifecycle>]
  [<lifecycle id="...">
    ...
  </lifecycle>]
  ...
  [<lifecycle id="...">
    ...
  </lifecycle>]

  [<scope id="compile" [mode="override|inherit"]>
    <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/> <!-- type is mandatory-->
    <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/>
    ...
    <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/>
  </scope>]
  [<scope id="...">
    ...
  </scope>]
  ...
  [<scope id="...">
    ...
  </scope>]

  [<plugins [mode="override|inherit"]>
    <!-- this is what pluginManagement was -->
  </plugins>]

  [<bindings [mode="override|inherit"]>
    <!-- this is what plugins was, we make explicit here that this is the binding of executions into the lifecycles -->
  </bindings>]

  [<platform id="..." [mode="override|inherit"]>
    <activation>
      <!-- define how we determine that this platform can be built in the current environment -->
    </activation>
    <!-- allow platform specific mixins -->
    [<mixin groupId="..." artifactId="..." [version="..."]/>]
    <!-- allow platform specific lifecycles -->
    [<lifecycle id="...">
      ...
    </lifecycle>]

    <!-- allow platform specific dependencies -->
    [<scope>
      ...
    </scope>]

    <!-- allow platform specific bindings... but plugin management is from the root only -->
    [<bindings>
      ...
    </bindings>]

    <!-- allow most of the other root tags except platform and packaging and deployment config -->
  </platform>]
  [<platform id="...">
    ...
  </platform>]
  ...
  [<platform id="...">
    ...
  </platform>]

  <!-- packaging is only allowed in poms with an id of "parent" or "mixin". It allows a parent/mixin to be used by different packaging ids and define specialized defaults -->
  [<packaging id="...">
    [<mixin groupId="..." artifactId="..." [version="..."]/>]
    <!-- allow platform specific lifecycles -->
    [<lifecycle id="...">
      ...
    </lifecycle>]

    <!-- allow platform specific dependencies -->
    [<scope>
      ...
    </scope>]

    <!-- allow platform specific bindings... but plugin management is from the root only -->
    [<bindings>
      ...
    </bindings>]

    <!-- allow most of the other root tags except platform and packaging and deployment config -->
  </packaging>]
  [<packaging id="...">
    ...
  </packaging>]
  ...
  [<packaging id="...">
    ...
  </packaging>]

  <!-- unsure if we still need profiles -->
  <!-- perhaps we still need properties -->
  <!-- TBD deployment config, repositories, etc -->

</project>
 

Some things that came to mind, in no particular order:

• scope becomes a build time only concern. Thus we can let users define custom scopes in their pom. If we let plugin executions declare scopes to resolve, we no longer need a compiler:testCompile goal as you can just have a second default execution of compiler:compile with different required scopes and different default configuration... bonus win, I can now add many different layers of test-compilation for integration tests, etc... each pulling in different scopes... ditto for surefire/failsafe... yeah integration tests

• we should let the user define lifecycles directly in the Pom (ok, maybe we don't *encourage it*)

• mixins can be properly considered... they only affect build time anyway

• Pom doesn't need to be XML any more... (maybe we want to keep XML though... just a less verbose form)

• does Maven 5 build Maven 2/3 projects?