You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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+ 

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?

 

Building the effective build time model would be:

 

  • Start with parent, add in matching packaging from parent, in Pom order, add each mix-in (including matching packaging from mix-in before processing subsequent mix-ins), finally apply local pom.

 

To compute effective lifecycle and build plan, allow platform activation to be considered... each platform is like a mini-sub project that can "run in parallel" (yes I need to doc this better...)
Issues to consider: (query project = MNG AND (fixVersion = "Issues to be reviewed for 4.x" OR component = FDPFC) if you think that other issues need to be considered, just add)
  • MNG-50 - Getting issue details... STATUS
  • MNG-177 - Getting issue details... STATUS  /  MNG-5652 - Getting issue details... STATUS  /  MNG-1977 - Getting issue details... STATUS  /  MNG-2316 - Getting issue details... STATUS  /  MNG-2316 - Getting issue details... STATUS  /  MNG-5867 - Getting issue details... STATUS  
  • MNG-193 - Getting issue details... STATUS
  • MNG-624 - Getting issue details... STATUS
  • MNG-683 - Getting issue details... STATUS
  • MNG-1867 - Getting issue details... STATUS  (effectively addressed above as we remove all "special" scopes replacing them with convention)
  • MNG-2216 - Getting issue details... STATUS  / MNG-3608 - Getting issue details... STATUS  (need to decide if we will have a global "configuration" section)
  • MNG-2916 - Getting issue details... STATUS
  • MNG-3326 - Getting issue details... STATUS  /  MNG-3826 - Getting issue details... STATUS  /  MNG-5650 - Getting issue details... STATUS
  • MNG-3397 - Getting issue details... STATUS  / MNG-5653 - Getting issue details... STATUS  (effectively addressed in the current proposal)
    • MNG-6061 - Getting issue details... STATUS  switching to a DSL should be considered... though I suspect a new compact XML would be less of an issue while retaining some ability to allow earlier maven versions to at least print semi-sensible errors if attempt is made to build new pom with old maven
  • MNG-3522 - Getting issue details... STATUS  (effectively superseded as you can augment the lifecycle from within the POM and thus provide any additional phases you require in order to ensure the sequencing required)
  • MNG-3726 - Getting issue details... STATUS  /  MNG-4506 - Getting issue details... STATUS  /  MNG-4921 - Getting issue details... STATUS
  • MNG-3879 - Getting issue details... STATUS  /  MNG-5926 - Getting issue details... STATUS
  • MNG-4173 - Getting issue details... STATUS  (should just do this for 5.0.0. No more plugin version "magic")
  • MNG-5102 - Getting issue details... STATUS  / MNG-5588 - Getting issue details... STATUS  (should be addressed with the current proposal, but need to review what the ask in this issue was to see if any gaps exist)
  • MNG-5384 - Getting issue details... STATUS  (this one is really important as we want to be able to enable light-weight multi-module builds that just don't fail where "clean install" would succeed - solving this will mean that the reactor can proceed across all modules as required in order to deliver the requirements of the "driving" module(s))
  • MNG-5517 - Getting issue details... STATUS  WONT FIX I do not see the value in moving from the range syntax to a less mathematically complete syntax
  • MNG-5563 - Getting issue details... STATUS  (perhaps it is a legitimate concern for plugins to require parameters that have defined values from somewhere... unclear if this affects the POM though) 
  • MNG-5654 - Getting issue details... STATUS  (effectively addressed above)
  • MNG-5657 - Getting issue details... STATUS  /  MNG-5659 - Getting issue details... STATUS  WONT FIX I do not see the value in splitting content out of the pom... that way leads to profiles.xml which was madness
  • MNG-5665 - Getting issue details... STATUS  (need to ensure that we address this need in the lifecycle declaration syntax)
  • MNG-5900 - Getting issue details... STATUS  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...


  • No labels