Design Considerations: Lifecycle and Plugin Handling for Maven 2.1
Relevant New Features
- Problem controlling whether aggregation happens before vs. after the main build
- Problems with aggregator mojos being bound into the lifecycle
- Others? Need to accumulate problems from JIRA...
We need to provide a standardized way to suppress one or more executions of a given mojo. This is usually required when a mojo is bound to the build via packaging or something in the POMs ancestry.
Need a way to organize the order of operations within a single lifecycle phase, in order to specify when a mojo binding should precede the standard bindings, etc.
Provide a mechanism for external tools that embed Maven, so they can register pre- or post-build hooks per project.
Need more information about specific needs here...it may be better to enable this within the embedder itself, rather than interfering with the standard lifecycle.
If we find that we must include build extensions in Maven's core classloader, then we'll need a way to adjust the artifact filter used to avoid double-loading a given dependency in the plugin and the core. In other words, this filter prevents the loading of plugin dependencies into the plugin's classloader in cases where that dependency already exists in the core...in cases where build extensions are used, we need to ensure that this filter takes those loaded extensions into consideration.
It would be useful to define the APIs exposed for plugin parameter injection using some sort of annotation or other tools. This would enable us to render a guide to plugin parameter expressions, and would remove the String-based logic associated with parameter injection. (Need more details here.)