...

[DESIGN

...

DISCUSSION

...

for

...

2.1

...

]

...

Atypical

...

Plugin

...

Use-Cases

The Parent Problem

When a child project is referenced by a parent POM, and that parent POM defines plugins to be run, those plugins may execute before or after the child modules build, depending on the child modules' usage of the <parent/> section of their POMs.

...

Non-aggregator and aggregator mojos alike have access to the list of projects in the current reactor, either using ${reactorProjects}, or using ${session}.getSortedProjects(). However, because project dependencies are resolved just-in-time, ahead of the mojo's execution, and according to the mojo's use of the @requiresDependencyResolution annotation, the full list of projects in the session (or the result of the ${reactorProjects} expression) WILL NOT have their dependencies resolved to the scope specified.TODO

Proposed changes for 2.1

Add projects="sub" and projects="all" as qualifiers to the @requiresDependencyResolution annotation

This doesn't represent anything fundamentally different in terms of artifact resolution. What's new is the scope of Maven's resolution efforts. The unqualified scope specification will result in the dependencies of the current project being resolved to that scope. When qualified with 'projects="all"', the same thing happens for all projects in the reactor. Finally, when qualified with 'projects="sub"', dependency resolution for that scope happens for the current project AND its descendant projects. This last qualifier is critical when taken with the changes to accommodate summary mojos (See the discussion on Aggregation, above). In many cases where summary mojos run, they will need information about ONLY those projects that are self-or-descendant for the current project. This helps the summary mojo escape the effects of running the build from an arbitrarily super-level of a large nested build structure.

Backward-compat considerations

The dependency-resolution features of Maven 2.0.x are fairly counter-intuitive when coupled with ${reactorProjects} or ${session}.getSortedProjects(), since it only resolves dependencies for the current project. Since this behavior is still intact by default, it should produce no compatibility problems.

The only uncertainty happens when considering whether QDox allows a value that's unattached to an attribute in mixed mode with other values that DO have attributes. For instance:

/**
 * @goal test
 * @requiresDependencyResolution test projects="all"
 */

If this doesn't work, it's no big problem to support two forms of the requiresDependencyResolution annotation. Of course, the old specification would be supported:

/**
 * @goal test
 * @requiresDependencyResolution test
 */

In addition, a new format would be introduced:

/**
 * @goal test
 * @requiresDependencyResolution scope="test" projects="all"
 */