...

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

   looks to add a layer of indirection to the lifecycle bindings such that, say the "compile" phase could be bound to a generic "compiler" goal and then another layer could define that for a specific project / packaging the "compiler" generic goal would be fulfilled by a specific plugin's goal execution.

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

   looks to define a specific plugin execution order within a phase. The driver for this use case is that the lifecycle cannot be customised so when a module needs a complex lifecycle in order to ensure correct inter-plugin execution order

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

   looks to introduce more advanced constraints on the lifecycle, such as "finally" concepts as well as fork-points in the lifecycle, such as "either install or deploy but not both"

Overview

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

Scope related changes

There is no specific set of themes here:

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

   looks to remove system scope.

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

   looks to introduce a scope that would allow mix-ins for dependencyManagement

Profile activation

The following issues are all focused on gaps in profile activation:

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

   looks to define profile deactivators which would be the inverse of profile activators. Some of the use cases seem a bit hacky, but as a principal being able to express activation via an inverse condition can be simpler for users to comprehend.

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

   looks to be able to have profiles activated based on the project version

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

   looks to make the activators into an extension point.

POM format

The following issues look to address deficiencies (perceved or otherwise) in the modelVersion 4.0.0 POM format:

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

   looks to switch to attributes for some of the more annoying verbosity in the POM

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

   looks to switch to attributes for some of the more annoying verbosity in the POM

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

   looks to switch from XML to a custom DSL

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

   looks to move the build/pluginManagement tag to the root level.

Mix-ins

The following issues look for mix-ins that allow content for the POM to be included from other sources:

• 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

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

<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="..." [afterversion="..."] | beforepackaging="..."]/>

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

  [<lifecycle<mixin idgroupId="...">
     artifactId="..." [version="...
  </lifecycle>"]/>]

  [<scope<mixin idgroupId="compile..." artifactId="..." [modeversion="override|inherit..."]/>]
  ...
  <dependency[<mixin groupId="..." artifactId="..." [platformIdversion="..."] version/>]

  [<lifecycle id="..." mode="override|inherit">
    <phase id="..." [classifierafter="..."] | typebefore="..."]/>
 <!-- type is mandatory-->
    <dependency groupId<phase id="..." artifactId="..." [platformId[after="..."] version="..." [classifier | before="..."] type="..."/>
    ...
    <dependency<phase groupIdid="..." artifactId[after="..." [platformId| before="..."] version="..." [classifier="..."] type="..."/>
  </scope>]
  [<scope/>

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

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

  [<bindings [mode="override|inherit"]>
    <dependency groupId="..." artifactId="..." [platformId="..."] version="..." [classifier="..."] type="..."/> <!-- thistype is whatmandatory-->
 plugins was, we make explicit here that this is the binding of executions into the lifecycles -->
  </bindings>]

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

  [<plugins [mode="override|inherit"]>
    <!-- this allowis platformwhat specificpluginManagement dependencieswas -->
    [<scope>
      ...</plugins>]

    </scope>]

[<bindings [mode="override|inherit"]>
    <!-- allowthis platformis specific bindings... but plugin management is from the root only what plugins was, we make explicit here that this is the binding of executions into the lifecycles -->
  </bindings>]

  [<bindings>
      <platform id="..." [mode="override|inherit"]>
    </bindings>]

<activation>
      <!-- allowdefine mosthow ofwe thedetermine otherthat rootthis tagsplatform exceptcan platformbe andbuilt packagingin andthe deploymentcurrent configenvironment -->
    </platform>]activation>
  [<platform id="...">
    ...
  </platform>]
  ...
  [<platform id <!-- allow platform specific mixins -->
    [<mixin groupId="...">
     artifactId="...
  </platform>]

" [version="..."]/>]
    <!-- packagingallow platform isspecific 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 lifecycles -->
    [<lifecycle id="...">
      ...
    </lifecycle>]

    <!-- allow platform specific dependencies -->
    [<packaging id="...">
<scope>
     [<mixin groupId="..." artifactId="..." [version="..."]/>]

    </scope>]

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

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

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

    <!-- allowpackaging mostis ofonly theallowed otherin rootpoms tagswith exceptan platformid andof packaging"parent" and deployment config or "mixin". It allows a parent/mixin to be used by different packaging ids and define specialized defaults -->
  </packaging>]
  [<packaging id="...">
    [<mixin groupId="...
  </packaging>]
  " artifactId="...
"  [<packaging idversion="..."]/>]
    ...
  </packaging>]

  <!-- unsure if we still need profiles -->
  <!-- perhaps we still need properties -->
  <!-- allow platform specific lifecycles -->
    [<lifecycle id="...">
      ...
    </lifecycle>]

    <!-- TBDallow deploymentplatform config,specific repositories,dependencies 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?

...

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

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

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

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

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

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

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

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

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

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

   (perhaps it is a legitimate concern for plugins to require parameters that have defined values from somewhere... unclear if this affects the POM though) 

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

  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...

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

  WONT FIX I do not see the value in splitting content out of the pom... that way leads to profiles.xml which was madness

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

  WONT FIX I do not see the value in splitting content out of the pom... that way leads to profiles.xml which was madness

...

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

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

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

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

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

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

...

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

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

   (should just do this for 5.0.0. No more plugin version "magic")

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

  WONT FIX I do not see the value in moving from the range syntax to a less mathematically complete syntax

...

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

   (since the symmetry will feed into the lifecycle definition syntax perhaps)

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

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

   (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)

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

   (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))

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

   (need to ensure that we address this need in the lifecycle declaration syntax)

...

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

   (effectively addressed above as we remove all "special" scopes replacing them with convention)

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

...

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

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

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

...

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

   /

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

   (effectively addressed in the current proposal)

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

   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

    [<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?

...

...

...

...