maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
Date Sat, 01 Aug 2015 14:56:04 GMT


ASF GitHub Bot commented on MNG-5805:

GitHub user atanasenko opened a pull request:

    MNG-5805: Fix NPE in LifecyclePhase#toString()


You can merge this pull request into a Git repository by running:

    $ git pull master

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #62
commit daa992989bc68e8bf9fba8b118bce0272e011eb4
Author: Anton Tanasenko <>
Date:   2015-08-01T14:02:52Z

    MNG-5805: Fix NPE in LifecyclePhase#toString()


> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---------------------------------------------------------------------------
>                 Key: MNG-5805
>                 URL:
>             Project: Maven
>          Issue Type: Improvement
>          Components: Plugins and Lifecycle
>            Reporter: Anton Tanasenko
>            Assignee: Jason van Zyl
>            Priority: Minor
>             Fix For: 3.3.6
> Currently, DefaultLifecycleMapping does not support mapping phases to goals with a custom
configuration (see maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It
is impossible to bind, say, an assembly plugin to 'package' phase within a custom packaging
type, since assembly plugin requires a meaningful configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a lifecycle for
a particular type of project (there's one for jar, a couple for wars and several more for
other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert such poms
to custom packaging types, leaving only a single parent with global config and pluginManagement.
But it is currently impossible, since we are using mostly standard plugins (only occasional
dedicated ones) to configure projects' lifecycles.
> I did some digging around and put together a relatively straightforward change to maven-core:
> It both introduces support for specifying configuration and dependencies for mojo executions:
> {code:xml}
> <install>
>   <mojos>
>     <mojo>
>       <goal>org.apache.maven.plugins:maven-install-plugin:2.4:install</goal>
>       <configuration>...</configuration>
>       <dependencies>...</dependencies>
>     </mojo>
>     <mojo>
>       ...
>     </mojo>
>   </mojos>
> </install>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> <install>org.apache.maven.plugins:maven-install-plugin:2.4:install, ...</install>
> {code}
> I will put together some its (as well as make sure that existing are running ok) and
create a pull request for both. Also, there are a couple of changes that break API in org/apache/maven/lifecycle/
and org/apache/maven/lifecycle/mapping/ How critical is it to mantain compatibility
in those two?
> ITS:

This message was sent by Atlassian JIRA

View raw message