...

[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.

...

Since the only truly safe way to run an aggregator mojo is from the command line, proper use of this feature serves to destroy the controlled vocabulary that helps to make Maven a compellingly portable tool. It also raises serious concerns about how to configure the aggregator mojo in a portable way, with the only clear way being an entry in the pluginManagement section of the top-level POM. Since the definition of "top-level POM" can vary according to whether you're building a project, product containing the project, distribution containing both, etc, this still leaves open the possibility of conflicting aggregator configurations within a single build.

Proposed changes for 2.1

Deprecate @aggregator and

...

further develop child-processing and child-summary support

...

from parent POMs

...

Introduce a new, special phase

...

: summarize

This might be implemented as a special isSummaryPhase() flag for lifecycle - phase specification, to allow introduction of multiple post-child phases. Pre-child processing can take place in the normal parent phase bindings, since parents will be forced to the head of the line, ahead of children (see The Parent Problem, above). Summary phases that are not specified at the end of the lifecycle would be parsed as runtime (core coding) errors

Implications

One serious implication of this change is that it would require Maven to track parent-child relationships within the reactor. This is critical to enable Maven to wait until the last descendant project of a particular POM has been built, before calling the new special summary phase.

Criteria for the execution of this new phase would be the same as other phases. That is, it would require that all preceding steps (phases/mojos) succeed. Failure ahead of this phase - if not configured using something like --fail-never - would prevent the summary phase from executing.

${subProjects} expression

...

Backward-compat considerations

TODOLegacy @aggregator mojos should be supported, at least for 2.1. However, their use should prompt a deprecation warning to the user.

Build Introspection

This is the ability to query the build for the set of changes it will make to the build state. It's useful for things like IDE tooling, eclipse:eclipse, and clean:clean, since it would allow the user to discover which additional resources it should pay attention to. In the case of IDE tooling, it would allow for addition of new source folder definitions corresponding to generated-source target directories and so forth. In the case of clean:clean, it would allow the plugin to determine which directories (outside of target/, that is) it should clear when it executes.

...

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.

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.TODO

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"
 */