1 files changed, 102 insertions, 0 deletions
diff --git a/framework/src/maven/apache-maven-3.3.3/maven-core/src/site/apt/getting-to-container-configured-mojos.apt b/framework/src/maven/apache-maven-3.3.3/maven-core/src/site/apt/getting-to-container-configured-mojos.apt
new file mode 100644
index 00000000..1c4a487d
--- /dev/null
+++ b/framework/src/maven/apache-maven-3.3.3/maven-core/src/site/apt/getting-to-container-configured-mojos.apt
@@ -0,0 +1,102 @@
+~~ Licensed to the Apache Software Foundation (ASF) under one
+~~ or more contributor license agreements.  See the NOTICE file
+~~ distributed with this work for additional information
+~~ regarding copyright ownership.  The ASF licenses this file
+~~ to you under the Apache License, Version 2.0 (the
+~~ "License"); you may not use this file except in compliance
+~~ with the License.  You may obtain a copy of the License at
+~~
+~~ http://www.apache.org/licenses/LICENSE-2.0
+~~
+~~ Unless required by applicable law or agreed to in writing,
+~~ software distributed under the License is distributed on an
+~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+~~ KIND, either express or implied.  See the License for the
+~~ specific language governing permissions and limitations
+~~ under the License.
+
+  ---
+  Getting to Plexus-configured Mojos
+  ---
+  John Casey
+  ---
+  29-April-2005
+
+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 system 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.
+