Selected Solution

Based on the attached discussion, this is the selected solution:

<plugin>
 <g/a/v>
 <configuration />
 <executions>
   <execution>
     <id />
     <configuration />
     <goals>
       <goal>...</goal>
       <goal>...</goal>
     </goals>
   </execution>
 </executions>
</plugin>

For backwards compat, we can keep the external goals, but deprecate them. They would form a default execution.

Executions with the same id are merged in an inheritence scenario. Goals within an execution could not be duplicated.

There is no per-goal configuration in the new format, as it can be done with multiple executions. This makes it less verbose.

For reports, it would be as follows:

<plugin>
 <g/a/v>
 <configuration />
 <reportSets>
   <reportSet>
     <id />
     <configuration />
     <reports>
       <report>...</report>
       <report>...</report>
     </reports>
   </reportSet>
 </reportSets>
</plugin>

...

Problem Statement

There appear to be some use cases for running the same goal twice. The current proposal is for this to be configured in the POM like so:

<plugin>
  <groupId>org.codehaus.modello</groupId>
  <artifactId>modello-maven-plugin</artifactId>
  <configuration>
    <model>maven.mdo</model>
  </configuration>
  <goals>
    <goal>
      <id>xpp3-reader</id>
      <configuration>
        <version>3.0.0</version>
      </configuration>
    </goal>
    <goal>
      <id>xpp3-reader</id>
      <configuration>
        <version>4.0.0</version>
      </configuration>
    </goal>
    <goal>
      <id>xpp3-writer</id>
      <configuration>
        <version>3.0.0</version>
      </configuration>
    </goal>
    <goal>
      <id>xpp3-writer</id>
      <configuration>
        <version>4.0.0</version>
      </configuration>
    </goal>
    .
    .
    .

This has some problems:

• it is very verbose and tedious
• the inheritence behaviour of merge can no longer be relied upon - do goal definitions merge together, or as new goal instances?
• has a similar affect on profiles that might want to call a goal again.

Potential solutions

Always Merge - make the mojo take multiple configurations

...

The downside of this apporach is that:

• it becomes complicated to specify different configurations in goals
• it may be desired to have different goals per configuration