Abstract
We're moving toward integrating mojos as first-class plexus components, while at the same time avoiding introducing required plexus dependencies into the mojo development model.
In order to really achieve this, we need mojo configurations (which are provided both in terms of static expressions that are just looked up, and in terms of user-provided configuration from properties or the POM). If these mojos are to be first-class components, the configuration from these various sources must be consolidated and injected using the container.
Currently, mojo configuration is done externally to the container, in the DefaultPluginManager in the maven-core API. In order to get from here to there, we need to do several things to add capability to the default configuration of plexus. This document will detail those changes.
Container Enhancements
ExpressionEvaluator
Currently, the expression evaluator used to resolve configuration values is the DefaultExpressionEvaluator, which is a local variable within the implementation of the BasicComponentConfigurator. This ExpressionEvaluator simply returns the expression itself as the resolved value, which adds very little value to the container. Things like $project.build.resources are not resolved, and result in a type mismatch for the member injection.
We need a replacement for DefaultExpressionEvaluator that is capable of traversing an object graph and extracting Object values, not just Strings.
ComponentConfigurator
Currently, the container uses BasicComponentConfigurator, to configure components. This wouldn't be a problem, except for the local instance of DefaultExpressionEvaluator used within. See the above discussion for more on why this evaluator is bad. We need to provide either an alternative implementation under a different roleHint, or else replace the BasicComponentConfigurator.
Other
We may need to define a new lifecycle/phase to contextualize a mojo right before it's used, and reset it's state afterward. Up to now, the approach of most plexus components has been to avoid instance state like the plague. With the current parameter passing model of mojos, this will not be possible, particularly when we move mojos to a singleton instantiation model, and then run a reactorized project...the successive calls may leave behind configuration artifacts from invocation to invocation.
Maven Modifications
DefaultPluginManager
s/getMojoConfiguration()/getConfiguration()/g
That should re-enable usage of mojo configuration. Ideally, we won't need any of the code that references this method, since the container should provide some way of recontextualizing the mojo, and all we would need to do is inject POM configuration via the lookup method or something.
PluginDescriptorBuilder
s/getMojoConfiguration()/getConfiguration()/g
That should be all there is to it.
MojoDescriptor
Remove set/getMojoConfiguration(..), as it will become obsolete.
MavenSession
We may need to enable the context injection here, since this will be instantiated per-project. If we always inject the same context parameters, and are careful to inject nulls where things are missing, we should be able to minimize reconfiguration artifacts injected from basic parameters.