Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

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

<p>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 &quot;exec-1&quot;.  But it is ok for the jar plugin to use &quot;exec-1&quot; if a different plugin also has an execution with ID &quot;exec-1&quot;.<br />
Plugins that are bound to the default lifecycles by maven are assigned a null execution id.</p>

<p>There are a couple of problems with the current system.</p>

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

<p>For example, to configure default execution of the maven jar plugin, settings must be applied to all executions of that plugin.</p>
<table class="wysiwyg-macro" data-macro-name="code" data-macro-default-parameter="xml" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGU6eG1sfQ&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
&lt;plugin>
  &lt;groupId>org.apache.maven.plugins&lt;/groupId>
  &lt;artifactId>maven-jar-plugin&lt;/artifactId>
  &lt;configuration>
    &lt;finalName>myjar&lt;/finalName>
  &lt;/configuration>
&lt;/plugin>
</pre></td></tr></table>
<p>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.</p>
<table class="wysiwyg-macro" data-macro-name="code" data-macro-default-parameter="xml" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGU6eG1sfQ&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
&lt;plugin>
  &lt;groupId>org.apache.maven.plugins&lt;/groupId>
  &lt;artifactId>maven-jar-plugin&lt;/artifactId>
  &lt;executions>
    &lt;execution>
      &lt;id>default-jar-execution&lt;/id>
      &lt;configuration>
        &lt;finalName>mainjar&lt;/finalName>
      &lt;/configuration>
    &lt;/execution>
    &lt;execution>
      &lt;id>extra-jar-execution&lt;/id>
      &lt;goals>
        &lt;goal>jar&lt;/goal>
      &lt;/goals>
      &lt;configuration>
        &lt;finalName>anotherjar&lt;/finalName>
      &lt;/configuration>
    &lt;/execution>
  &lt;/exectutions>
&lt;/plugin>
</pre></td></tr></table>

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

<p>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.</p>
<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
mvn idea:idea
</pre></td></tr></table>
<p>Currently the only way to configure two command line executions separately is by passing all parameters in through the command line.</p>

<h1>Proposals</h1>

<p>These are the various proposals to solve this issue, in order of being documented:</p>

<h2> Proposal #1</h2>

<h3>Lifecycle execution defaults</h3>

<p>The goal executions attached to the default lifecycle could be given a default execution ID that looks like:</p>
<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
default-lifecycle-&lt;goal>
</pre></td></tr></table>
<p>For example the two executions of the compiler plugin would be assigned execution IDs<br />
default-lifecycle-compile<br />
default-lifecycle-testCompile</p>

<p>These names will be displayed in Maven's log output like this:</p>
<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
[INFO] [compiler:compile {execution: default-lifecycle-compile}]
[INFO] [compiler:testCompile {execution: default-lifecycle-testCompile}]
</pre></td></tr></table>
<p>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.</p>

<h3>Enhanced command line goal syntax.</h3>

<p>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:</p>
<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
mvn eclipse:eclipse{execution-1}
</pre></td></tr></table>
<p>This would tell maven to use the configuration contained in &quot;execution-1&quot; of the plugin when running the goal.</p>

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

<h2>Proposal #2</h2>

<p>This proposal is a counter-proposal to Proposal #1.</p>

<h3>Lifecycle execution defaults</h3>

<p>The goal executions attached to the default lifecycle for any plugin would be grouped by phase and each phase's execution given a default execution ID that looks like:</p>
<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
lifecycle:&lt;packaging>:&lt;phase>
</pre></td></tr></table>
<p>For example the two executions of the compiler plugin in the standard jar packaging would be assigned execution IDs<br />
lifecycle:jar:compile<br />
lifecycle:jar:test-compile</p>

<p>These names will be displayed in Maven's log output like this:</p>
<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
[INFO] [compiler:compile {execution: lifecycle:jar:compile}]
[INFO] [compiler:testCompile {execution: lifecycle:jar:test-compile}]
</pre></td></tr></table>
<p>A potential problem with this is that all goals of a plugin bound to a phase must use the same configuration. Another potential problem is that of duplication if the configuration needs to be overridden for both the jar and war packaging. (Two solutions to this are: 1. remove the specification of packaging in the first place (lifecycle:&lt;phase&gt;) 2. use of wildcards (lifecycle:*:&lt;goal&gt;) note that the use of wildcards allows of significant reduction in duplication of configurations that must be different from the plugin's default configuration</p>

<h3>No enhanced command line goal syntax.</h3>

<p>The issue with invoking executions that are attached to a phase in the lifecycle directly, is that for proper execution of the plugin goal, Maven should really execute all lifecycle phases up to (but not including) the phase that the plugin is bound to... in such a situation, it would seem better to just execute that phase directly, or define a special profile which binds the plugin to early phases (e.g. validate) and specifies the default goal as the highest early phase used so that execution with just specifying the profile would execute the plugin for the task at hand, e.g.</p>
<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
&lt;project
    xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  &lt;modelVersion>4.0.0&lt;/modelVersion>
  ...
  &lt;profiles>
    &lt;profile>
      &lt;id>special-checks&lt;/id>
      &lt;build>
        &lt;defaultGoal>validate&lt;/defaultGoal>
        &lt;plugins>
          &lt;plugin>
            &lt;groupId>org.apache.maven.plugins&lt;/groupId>
            &lt;artifactId>maven-enforcer-plugin&lt;/artifactId>
            &lt;executions>
              &lt;execution>
                &lt;phase>validate&lt;/phase>
                &lt;goals>
                  &lt;goal>display-info&lt;/goal>
                &lt;/goals>
                &lt;configuration>
                  ... &lt;!-- this is the custom config for special-checks -->
                &lt;/configuration>
              &lt;/execution>
            &lt;/executions>
          &lt;/plugin>
        &lt;/plugins>
      &lt;/build>
    &lt;/profile>
  &lt;/profiles>
&lt;/project>
</pre></td></tr></table>

<h3>References</h3>