Selected Solution
Based on the attached discussion, this is the selected solution:
Code Block | ||||
---|---|---|---|---|
| ||||
<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:
Code Block | ||||
---|---|---|---|---|
| ||||
<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:
Code Block | ||||
---|---|---|---|---|
| ||||
<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