Page History

...

<project modelVersion="5.0.0" [groupId="..."] artifactId="..." [version="..."] template="...">
  [<parent [groupId="..."] [artifactId="..."] [version="..."] [relativePath="..."]/>]
  [<mixin [groupId="..."] [artifactId="..."] [version="..."] [relativePath="..."]/>]
  [<extensions [mode="override|inherit"]>
    ...
</project>

The following are mandatory elements:

  </extensions>]
  [<lifecycle id="..." mode="override|inherit">
    ...
  </lifectcle>]
  ...
</project>

The following are mandatory elements:

• modelVersion attribute - containing the model version of the POM.
• modelVersion attribute - containing the model version of the POM.
• artifactId attribute - containing the artifactId of the project
• template attribute - containing the identifier of the template / packaging that will be used as the initial basis for this project's conventions

...

• groupId attribute - containing the groupId of the project. If this attribute is missing then the parent element must be present and the groupId will be inherited from the parent project.
• version attribute - containing the version of the project. If this attribute is missing then the parent element must be present and the version will be inherited from the parent project.
• parent element (cardinality 0-1) - containing at a minimum either the GAV of the parent project or the relative path to the parent project. Where more than the minimum required information is supplied, the additional information will be used to validate the parent project reference.

<parent> element

• mixin elements (cardinality 0-N) - containing at a minimum either the GAV of the mix-in project or the relative path to the mix-in project. Where more than the minimum required information is supplied, the additional information will be used to validate the mix-in project reference.
• extensions element (cardinality 0-1) - containing the extensions to enable for this project.
• lifecycle elements (cardinality 0-N) - containing lifecycle customisations for this project.

<parent> element

The parent element identifies the parent project from which conventions will The parent element identifies the parent project from which conventions will be inherited.

<parent [groupId="..."] [artifactId="..."] [version="..."] [relativePath="..."]/>

...

• If the relativePath attribute is present, no other attributes are required:

  Code Block
  xml xml
  <parent relativePath="..."/>

  This indicates that the parent project can be found on disk at the supplied relative path and the conventions should be inherited from that project. Specifying the additional attributes of groupId or artifactId while the version attribute is unspecified will indicate that the build should fail if the project at the supplied relative path does not match the specified groupId or artifactId. If all three of the groupId, artifactId and version attributes are missing then a mismatch at the supplied relative path will not be fatal as the parent can be resolved from the reactor/repository.

• Specifying the GAV of the parent project:

  Code Block
  xml xml
  <parent groupId="..." artifactId="..." version="..."/>

  This indicates that the parent project should be resolved from the reactor / repository. If the relativePath element is present then in prior to the the reactor / repository the project at the specified relative path will be validated against the supplied groupId, artifactId and version and used in the event of a match.

The following are the attributes:

• groupId attribute - containing the groupId of the parent project. 
• artifactId attribute - containing the artifactId of the parent project
• version attribute - containing the version of the parent project. 
• relativePath attribute - containing the relative path to the parent project.

• supplied groupId, artifactId and version and used in the event of a match.

The following are the attributes:

• groupId attribute - containing the groupId of the parent project. 
• artifactId attribute - containing the artifactId of the parent project
• version attribute - containing the version of the parent project. 
• relativePath attribute - containing the relative path to the parent project.

<mixin> element

The mixin element identifies additional projects from which conventions will be inherited.

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

Technically from a schema perspective all attributes are optional, however there are two minimum valid sets of attributes:

• If the relativePath attribute is present, no other attributes are required:

  Code Block
  xml xml
  <mixin relativePath="..."/>

  This indicates that the mix-in project can be found on disk at the supplied relative path. Specifying the additional attributes of groupId or artifactId while the version attribute is unspecified will indicate that the build should fail if the project at the supplied relative path does not match the specified groupId or artifactId. If all three of the groupId, artifactId and version attributes are missing then a mismatch at the supplied relative path will not be fatal as the mix-in can be resolved from the reactor/repository.

• Specifying the GAV of the mix-in project:

  Code Block
  xml xml
  <mixin groupId="..." artifactId="..." version="..."/>

  This indicates that the mix-in project should be resolved from the reactor / repository. If the relativePath element is present then in prior to the the reactor / repository the project at the specified relative path will be validated against the supplied groupId, artifactId and version and used in the event of a match.

The following are the attributes:

• groupId attribute - containing the groupId of the mix-in project. 
• artifactId attribute - containing the artifactId of the mix-in project
• version attribute - containing the version of the mix-in project. 
• relativePath attribute - containing the relative path to the mix-in project.

<extensions> element

The extensions element identifies extensions to be enabled for this project.

<extensions [mode="override|inherit"]>
  [<extension [groupId="..."] [artifactId="..."] [version="..."] [relativePath="..."]/>]
  ...
</extensions> 

There is one attribute:

• mode attribute - when specified as override then any inherited extensions are ignored and the full set of extensions to be enabled is contained within this element. When specified as inherit - the default - then the inherited extensions are merged with the extensions contained within this element. In the case of duplicate groupId:artifactId entries, the version declared in this project will take precedence.

There can be 0-N extension elements.

<extension> element

The extension element identifies additional projects containing extensions to enable for the project.

<extension [groupId="..."] [artifactId="..."] [version="..."] [relativePath="..."]/>

Technically from a schema perspective all attributes are optional, however there are two minimum valid sets of attributes:

• If the relativePath attribute is present, no other attributes are required:

  Code Block
  xml xml
  <extension relativePath="..."/>

  This indicates that the extension project can be found on disk at the supplied relative path. Specifying the additional attributes of groupId or artifactId while the version attribute is unspecified will indicate that the build should fail if the project at the supplied relative path does not match the specified groupId or artifactId. If all three of the groupId, artifactId and version attributes are missing then a mismatch at the supplied relative path will not be fatal as the extension can be resolved from the reactor/repository.

• Specifying the GAV of the extension project:

  Code Block
  xml xml
  <extension groupId="..." artifactId="..." version="..."/>

  This indicates that the extension project should be resolved from the reactor / repository. If the relativePath element is present then in prior to the the reactor / repository the project at the specified relative path will be validated against the supplied groupId, artifactId and version and used in the event of a match.

The following are the attributes:

• groupId attribute - containing the groupId of the extension project. 
• artifactId attribute - containing the artifactId of the extension project
• version attribute - containing the version of the extension project. 
• relativePath attribute - containing the relative path to the extension project.

TODO resolve the inheritance problem

We have multiple places where things are coming from...

• parent
• mix-ins
• extensions

we need a model of inheritance that is easy for people to understand.

First stab:

• complete each parent/mixin's project model before inheriting.
  • PROs:
    • We do not have as much complexity, you just help:effective-pom on the parent, and mixins to see what they are defining and hence pulling in
  • CONs
    • What about mixin version conflict? If the parent brings in one mixin and then we explicitly state another version of that mixin and finally explicitly state a 3rd mixin that transitive states a third version of the same mixin.
      If we flatten first, it is very likely that we could have some cruft left over from one of the other versions

Second stab:

• process parent inheritance by injecting pseudo mixin nodes from the parent and then de-dup
  • CONs
    • I'm not even sure what I am saying here

I think we need to build the tree of mixins, resolve the closest version (with tree pruning) and then apply them...

Then after that, we can start to build the tree of extensions...

This is a pain!

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="..."] template="...">
  [<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>]

  [<extensions [mode="override|inherit"]>
    <extension groupId="..." artifactId="..." version="..."/>
    ...
  </extensions>]
  [<plugins [mode="override|inherit"]>
    <!-- this is what pluginManagement was -->
    <plugin groupId="..." artifactId="..." version="...">
      ...
    </plugin>
    ...
  </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>]

  <!-- packagingtemplate is only allowed in poms with an id of "parent" or "mixin". It allows a parent/mixin to be used by different packagingtemplate ids and define specialized defaults -->
  [<packaging<template 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>template>]
  [<packaging<template id="...">
    ...
  </packaging>template>]
  ...
  [<packaging<template id="...">
    ...
  </packaging>template>]

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

</project>
 

...