Return-Path: 
 <issues-return-101587-apmail-maven-issues-archive=maven.apache.org@maven.apache.org>
X-Original-To: apmail-maven-issues-archive@minotaur.apache.org
Delivered-To: apmail-maven-issues-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 7E46417A85
	for <apmail-maven-issues-archive@minotaur.apache.org>;
 Sat, 18 Apr 2015 21:13:59 +0000 (UTC)
Received: (qmail 35323 invoked by uid 500); 18 Apr 2015 21:13:59 -0000
Delivered-To: apmail-maven-issues-archive@maven.apache.org
Received: (qmail 35204 invoked by uid 500); 18 Apr 2015 21:13:59 -0000
Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@maven.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@maven.apache.org>
List-Post: <mailto:issues@maven.apache.org>
List-Id: <issues.maven.apache.org>
Reply-To: dev@maven.apache.org
Delivered-To: mailing list issues@maven.apache.org
Received: (qmail 35193 invoked by uid 99); 18 Apr 2015 21:13:58 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Apr 2015 21:13:58 +0000
Date: Sat, 18 Apr 2015 21:13:58 +0000 (UTC)
From: "Anton Tanasenko (JIRA)" <jira@apache.org>
To: issues@maven.apache.org
Message-ID: <JIRA.12822100.1429389038000.40603.1429391638606@Atlassian.JIRA>
In-Reply-To: <JIRA.12822100.1429389038000@Atlassian.JIRA>
References: <JIRA.12822100.1429389038000@Atlassian.JIRA>
 <JIRA.12822100.1429389038016@arcas>
Subject: [jira] [Updated] (MNG-5805) Custom packaging types: configuring
 DefaultLifecycleMapping mojo executions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


     [ https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anton Tanasenko updated MNG-5805:
---------------------------------
    Description: 
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: https://github.com/atanasenko/maven/commit/19f970b60f3fd8f7e0ba6ce9f74b892190125354?w=1

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>
      <confguration>...</confguration>
      <dependencies>...</dependencies>
    </mojo>
    <mojo>
      ...
    </mojo>
  </mojos>
</install>
{code}
as well as retains support for existing mapping syntax:
<install>org.apache.maven.plugins:maven-install-plugin:2.4:install, ...</install>

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/Lifecycle.java and org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to mantain compatibility in those two?


  was:
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: https://github.com/atanasenko/maven/commit/19f970b60f3fd8f7e0ba6ce9f74b892190125354?w=1

It both introduces support for specifying configuration and dependencies for mojo executions:
<install>
  <mojos>
    <mojo>
      <goal>org.apache.maven.plugins:maven-install-plugin:2.4:install</goal>
      <confguration>...</confguration>
      <dependencies>...</dependencies>
    </mojo>
    <mojo>
      ...
    </mojo>
  </mojos>
</install>

as well as retains support for existing mapping syntax:
<install>org.apache.maven.plugins:maven-install-plugin:2.4:install, ...</install>

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/Lifecycle.java and org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to mantain compatibility in those two?



> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---------------------------------------------------------------------------
>
>                 Key: MNG-5805
>                 URL: https://issues.apache.org/jira/browse/MNG-5805
>             Project: Maven
>          Issue Type: Improvement
>          Components: Plugins and Lifecycle
>            Reporter: Anton Tanasenko
>            Priority: Minor
>
> 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: https://github.com/atanasenko/maven/commit/19f970b60f3fd8f7e0ba6ce9f74b892190125354?w=1
> 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>
>       <confguration>...</confguration>
>       <dependencies>...</dependencies>
>     </mojo>
>     <mojo>
>       ...
>     </mojo>
>   </mojos>
> </install>
> {code}
> as well as retains support for existing mapping syntax:
> <install>org.apache.maven.plugins:maven-install-plugin:2.4:install, ...</install>
> 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/Lifecycle.java and org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to mantain compatibility in those two?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)