Versions Compared

Old Version 20

changes.mady.by.user Arnaud Heritier

Saved on

compared with

New Version Current

changes.mady.by.user Dennis Lundberg

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Page properties


Status
Status
titleDRAFT
Version
 

Issue(s)
 

Sources
 

Developer(s)
Stephen Connolly


Status

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

...

Table of Contents

Introduction


Excerpt

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.

...

  • Jira
    serverASF JIRA
    serverId5aa69414-a9e9-3523-82ec-879b028fb15b
    keyMNG-4506
     (probably could be handled as maven-site-plugin configuration) looks to allow defining a different site deployment URL for SNAPSHOT versions of the project compared with release versions)
  • Jira
    serverASF JIRA
    serverId5aa69414-a9e9-3523-82ec-879b028fb15b
    keyMNG-2216
     looks for the ability to define the default encodings to be used when reading files (and optionally when writing files)
  • Jira
    serverASF JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverId5aa69414-a9e9-3523-82ec-879b028fb15b
    keyMNG-4149
     Extend POM to support encoding parameter per (test) resource ( project.build.resources[].resource.sourceEncoding )
  • Jira
    serverASF JIRA
    serverId5aa69414-a9e9-3523-82ec-879b028fb15b
    keyMNG-3608
     looks for the ability to define the default encodings to be used when writing the site reporting files

...

DECISION: The 5.0.0 POM will remove the distinction between build and reporting relying rather on lifecycle specific binding declarations

AFFECTS:  


Project Object Model

<project> element

...

  • 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

...

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:

Code Block
xml
xml
<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>]

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

  <!-- 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:

...