Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 3 Next »

Maven 2.0.x allows multiple plugin executions to be defined. These can run with the same or different goals, and can run in the same or different build phases. The executions can each be configured differently and/or they can all share a default configuration. Each plugin that is bound to one of the maven lifecycles is given an execution.

Each execution of a plugin must have a unique ID among the other executions of that plugin. For example, the jar plugin cannot have two executions that both use the ID "exec-1". But it is ok for the jar plugin to use "exec-1" if a different plugin also has an execution with ID "exec-1".
Plugins that are bound to the default lifecycles by maven are assigned a null execution id.

There are a couple of problems with the current system.

1. There is no way to directly access the execution configuration of plugins bound by the default lifecycles.

For example, to configure default execution of the maven jar plugin, settings must be applied to all executions of that plugin.

This works fine when there is only a single execution of a given plugin goal. But when there are multiple executions, it would often be preferable to be able to apply settings only to the specific execution of the plugin.

2. There is no way to separate configurations for command line executions of different goals in the same plugin.

Currently, the main plugin configuration section can be used to define settings to be used when executing a plugin from the command line. Unfortunately, these settings are applied to all executions of the plugin. So for example, it might be desirable to have two different preset configurations for the maven idea plugin.

Currently the only way to configure two command line executions separately is by passing all parameters in through the command line.


Lifecycle execution defaults

The goal executions attached to the default lifecycle could be given a default execution ID that looks like:

For example the two executions of the compiler plugin would be assigned execution IDs

These names will be displayed in Maven's log output like this:
[INFO] [compiler:compile

Unknown macro: {execution}

[INFO] [compiler:testCompile

Unknown macro: {execution}


A potential problem with this is that it is possible in the future that a single goal will need to be bound to the default lifecycle twice. This would cause a name conflict, and would prevent the two goals from being configured separately. This issue is addressed in the next part.

Enhanced command line goal syntax.

In order to link a command line invocation of a plugin with a specific execution in a pom, the goal syntax could be enhanced to include an execution. For example:

This would tell maven to use the configuration contained in "execution-1" of the plugin when running the goal.

In addition, this syntax could be applied to the components.xml file in maven core (where the default plugins are mapped to the lifecycles) to resolve name conflicts in the rare cases where the same goal needs to be applied twice in a default lifecycle.



  • No labels