// 3 the component model -> interfaces for the plugin

// The plugin manager should load up a directory structure of plugins.
// - a plugin per directory where the plugin is present with its deps
// - a plugin that has its dependencies packaged up with it
// - implement filters and create a test where a plugin fails if the right classes are not filtered
// - plugins with a dependency the same as the core but different versions, make it fail then fix it

  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

     *
     * <p><b>Context-sensitive interpretation:</b>
     * A dependency with this path type will not necessarily be placed on the class-path.
     * There are two circumstances where the dependency may nevertheless be placed somewhere else:
     * </p>
     * <ul>
     *   <li>If {@link #MODULES} path type is also set, then the dependency can be placed either on the

import static org.junit.jupiter.api.Assertions.assertTrue;

/**
 * A test which demonstrates maven's recursive inheritance where
 * a distinct value is taken from each parent contributing to
 * the final model of the project being assembled. There is no
 * overriding going on amongst the models being used in this test:
 * each model in the lineage is providing a value that is not present

        // We are doing something like "mvn resources:resources" where no version is specified but this
        // project we are working on has the version specified in the POM so the version should come from there.
        File pom = getProject("project-basic");
        MavenSession session = createMavenSession(pom);

   |
   | For example, if you have an integration testing plugin - like cactus - that needs to know where
   | your Tomcat instance is installed, you can provide a variable here such that the variable is
   | dereferenced during the build process to configure the cactus plugin.
   |

        // I'm fully aware that the file could just be moved using File.rename but
        // there are bugs in various JVM that have problems doing this across
        // different filesystem. So we'll incur the small hit to actually copy
        // here and be safe. jvz.
        // ----------------------------------------------------------------------------

        try {

        // to specify the absolute path to these files in a customized components.xml
        // file. Ideally, we'd do full pattern-evaluation against the sysprops, but this
        // is a first step. There are several replacements below, in order to normalize
        // the path character before we operate on the string as a regex input, and
        // in order to avoid surprises with the File construction...

     */
    private final List<Path> paths;

    /**
     * The file paths of all dependencies, dispatched according the Java options where to place them.
     */
    private final Map<PathType, List<Path>> dispatchedPaths;

    /**
     * The dependencies together with the path to each dependency.
     */

     |
     +--- maven.properties
+-----+

* Group configuration

 As far as properties go for an entire build the maven.properties could be placed at
 the top of the group but I'm not really sure how this might work. There could probably
 also be a directory for plugins.xml and maven.properties.

* Project configuration

 At the project level all configuration is achieved by tweaking the POM. One of the differences between