Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Many Mojos (e.g. the compiler) execute in different phases of the build lifecycle using different "configurations". With the current JavaDoc and MNG-2521 annotations, a Mojo cannot be annotated with more than one goal. Multiple "configurations" are done by subclassing a Mojo for each "configuration", e.g. CompilerMojo and TestCompilerMojo, which are virtually identical except parameter annotations and attribute names. With MNG-2521, the proposal is to extend the annotations to allow a Mojo to be annotated with multiple goals.

For this, list annotations should be introduced for each annotation (Goal, Parameter and Component). Each member of the list should have an optional attribute specifying for which goal the annotation is. If this attribute is missing, the annotation should be valid for all goals.

Example for a CompilerMojo

Code Block
    @Goal(goal = "compile", phase = "compile", requiresDependencyResolution = "compile"),
    @Goal(goal = "testCompile", phase = "test-compile", requiresDependencyResolution = "test"))
public class CompilerMojo extends AbstractMojo {

    @Parameter(expression = "${basedir}", required = true, readonly = true) // Valid for all goals
    private File basedir;

        @Parameter(goal = "compile", expression = "${project.compileSourceRoots}"), // Valid only for goal "compile"
        @Parameter(goal = "testCompile", expression = "${project.testCompileSourceRoots}")) // Valid only for goal "testCompile"
    private List compileSourceRoots;

Saves two classes and some typing.

When a parameter needs to have different names for different goals (e.g. "includes" and "testIncludes"), you can use setters:

Code Block
private List includes;

@Parameter(goal = "compile), // Valid only for goal "compile"
public void setIncludes(List includes) {
    this.includes = includes;

@Parameter(goal = "testCompile")) // Valid only for goal "testCompile"
public void setTestIncludes(List includes) {
    this.includes = includes;

On the long run, it would be nice to decouple a parameter name from the underlying attribute or method name, and allow the parameter name to be specified in the annotation.