Versions Compared

Old Version 4

changes.mady.by.user John Casey

Saved on

compared with

New Version Current

changes.mady.by.user John Casey

Saved on

Key

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

Design Considerations: Lifecycle and Plugin Handling for Maven 2.1

Proposals

  1. Suppression, Ordering, and Replacement of Plugins and Mojos Bindings

Relevant New Features

  1. Deterministic Lifecycle Planning

Refactoring Aggregation

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

Suppression of Mojos and Executions

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.

Fine-grained Ordering of Phase Bindings

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.

Super-lifecycle

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.

Flexible Artifact Filtering for Maven's Core Classloader

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.

Method for Defining Available Plugin Expressions

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