- we also seem to have information like the plugin lifecycle model that's buried inside the maven execution model
- we also seem to have artifact information tangled inside the plugin model
- we have to deal with scripting implementations (groovy, beanshell, ruby)
- we need to deal with a shared context for plugins, like the guarded mojos

 Features like transitive dependencies and the new parent specification mechanism. The problem we run into is
 that currently we have information about a project scattered across the project.xml and the
 various properties files. What needs to be done is to encapsulate all of this in the POM.

 Typically users parameterize the use of plugins, or have custom values like ${user.name}

     * This method will record extra information as well, like plugin occurrence or declaration location.
     */
    void reportPluginValidationIssue(
            IssueLocality locality, MavenSession mavenSession, MojoDescriptor mojoDescriptor, String issue);

    /**
     * Reports plugin Mojo issues applicable to the Mojo itself.
     * <p>
     * This method will record extra information as well, like plugin occurrence or declaration location.
     */

       for the change (usually before you start working on it).  Trivial changes like typos do not
       require a JIRA issue. Your pull request should address just this issue, without
       pulling in other changes.
 - [ ] Each commit in the pull request should have a meaningful subject line and body.
 - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`,
       where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue.

      <releases>
        <!-- That's the boolean POM field we would like to interpolate -->
        <enabled>${releasesEnabled}</enabled>
      </releases>
    </repository>
  </repositories>

  <build>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <!-- That's the boolean POM field we would like to interpolate -->
        <filtering>${filter.resources}</filtering>

        } else {
            /*
             * MNG-4900: Hack to workaround deficiency of legacy API which makes it impossible for plugins to access the
             * global profile manager which is required to build a POM like a CLI invocation does. Failure to consider
             * the activated profiles can cause repo declarations to be lost which in turn will result in artifact

     * @param externalRepositories The external (and already mirrored) repositories to merge into the result list, may
     *            be {@code null}.
     * @param request The project building request holding further settings like repository settings, must not be
     *            {@code null}.
     * @return The effective artifact repositories, never {@code null}.
     * @throws InvalidRepositoryException
     */

  <offline>false</offline>
  -->

  <!-- pluginGroups
   | This is a list of additional group identifiers that will be searched when resolving plugins by their prefix, i.e.
   | when invoking a command line like "mvn prefix:goal". Maven will automatically add the group identifiers
   | "org.apache.maven.plugins" and "org.codehaus.mojo" if these are not already contained in the list.
   |-->
  <pluginGroups>
    <!-- pluginGroup

  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

        return systemProperties;
    }

    /**
     * Sets the system properties to use for interpolation and profile activation. The system properties are collected
     * from the runtime environment like {@link System#getProperties()} and environment variables.
     *
     * @param systemProperties The system properties, may be {@code null}.
     * @return This context, never {@code null}.
     */