// replaces?
        AbstractRepositoryMetadata repoMetadata = (AbstractRepositoryMetadata) metadata;
        this.metadata.merge(repoMetadata.getMetadata());
    }

    public void merge(ArtifactMetadata metadata) {
        // TODO not sure that it should assume this, maybe the calls to addMetadata should pre-merge, then artifact

 * property {@code maven.ext.class.path} on the command line. As soon as dependency injection is set up, Maven
 * looks up all implementers of this interface and calls their {@link #init(Context)} method. Note:
 * Implementors are strongly advised to inherit from {@link AbstractEventSpy} instead of directly implementing this
 * interface.
 * @since 3.0.2
 */

    /**
     * Wraps an arbitrary object with an {@link ObjectBasedValueSource} instance, then
     * wraps that source with a {@link PrefixedValueSourceWrapper} instance, to which
     * this class delegates all of its calls.
     */
    public static class PrefixedObjectValueSource extends AbstractDelegatingValueSource
            implements QueryEnabledValueSource {

        /**

          </description>
        </field>
      </fields>
      <codeSegments>
        <codeSegment>
          <version>1.2.0+</version>
          <comment>Generated hashCode() and equals() based on identifier also calls its super, which breaks comparison
          </comment>
          <code>
            <![CDATA[
    /**
     * Computes a hash value based on {@link #getType()} and {@link #getProvides()} values.
     */

        // We are forcing the use of the plugin realm for all lookups that might occur during
        // the lifecycle that is part of the lookup. Here we are specifically trying to keep
        // lookups that occur in contextualize calls in line with the right realm.
        ClassRealm oldLookupRealm = container.setLookupRealm(pluginRealm);

        ClassLoader oldClassLoader = Thread.currentThread().getContextClassLoader();

  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

        verifier.verify(logger, calls(1)).debug("Importing foreign packages into class realm {}", "maven.api");
        verifier.verify(logger, calls(1)).debug("  Imported: {} < {}", "group1:artifact1", "test");
        verifier.verify(logger, calls(1)).debug("  Excluded: {}", "group1:artifact2:ext:classifier1:null");
        verifier.verify(logger, calls(1))

 ${project.name}
 -----
 Hervé Boutemy
 -----
 2021-07-11
 -----

${project.name}

 ${project.description}

* References

 * <<<mvn>>> invocation can be customized through pre-invocation script calls, that can be disabled by setting <<<MAVEN_SKIP_RC>>> environment variable:

*----------+--------------------------------------------+-----------------------+
||         || system level                              || user level 

import org.apache.maven.api.services.DependencyResolverResult;

/**
 * The result of collecting dependencies with a dependency resolver.
 * New instances are initially empty. Callers must populate with calls
 * to the following methods, in that order:
 *
 * <ul>
 *   <li>{@link #addOutputDirectory(Path, Path, PathModularizationCache)} (optional)</li>

 *
 * <p>One path type is handled in a special way: unlike other options,
 * the paths specified in a {@code --patch-module} Java option is effective only for a specified module.
 * This type is created by calls to {@link #patchModule(String)} and a new instance must be created for
 * every module to patch.</p>
 *
 * <p>Path types are often exclusive. For example, a dependency should not be both on the Java class-path