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