<association>
            <type>String</type>
            <multiplicity>*</multiplicity>
          </association>
          <description><![CDATA[Artifacts in the format <code>groupId:artifactId</code>. All the ones listed here are filtered (i.e. removed) from plugin and build extension class realms,
          i.e. referencing any of those coordinates in plugin/build extension dependencies has no effect.]]>
          </description>
        </field>

        INLINE, // inline, each "internal" problem one line next to mojo invocation
        SUMMARY, // at end, list of plugin GAVs along with ANY validation issues
        BRIEF, // each "internal" problem one line next to mojo invocation
        // and at end list of plugin GAVs along with "external" issues
        VERBOSE // at end, list of plugin GAVs along with detailed report of ANY validation issues
    }

import org.apache.maven.api.annotations.Experimental;
import org.apache.maven.api.annotations.Nonnull;

/**
 * A listener for session events.
 * TODO: open this to other events like similar to {@code org.apache.maven.eventspy.EventSpy}
 *
 * @since 4.0.0
 */
@Experimental
@FunctionalInterface
@Consumer
public interface Listener {
    void onEvent(@Nonnull Event event);

          </association>
        </field>
      </fields>
      <comment>We could probably have a specific element for a dev mailing list for things like CI,
        and maybe even a specific element for the user and scm mailing lists. Then leave the more
        lose structure for any other type of mailing list.</comment>
      <codeSegments>
        <codeSegment>
          <version>4.0.0+</version>
          <code>

            than specifying a value for finalName directly in the plugin configuration section. It is also useful to
            ensure that - for example - a List-typed parameter which expects items of type Artifact doesn't get a List
            full of Strings.
          </description>
        </field>
        <field>
          <name>description</name>
          <version>1.0.0+</version>

 * under the License.
 */
package org.apache.maven.artifact.resolver;

import org.apache.maven.artifact.Artifact;
import org.apache.maven.artifact.versioning.VersionRange;

/**
 * Listens to the resolution process and handles events.
 *
 */
@Deprecated
public interface ResolutionListener {
    String ROLE = ResolutionListener.class.getName();

    int TEST_ARTIFACT = 1;

        assertThat(projects, hasItem(pluginLevelDepProject));

        // the declaring project MUST be listed after the plugin and its plugin-level dep, though.
        assertEquals(declaringProject, projects.get(3));
    }

    @Test
    void testPluginDependenciesInfluenceSorting_DeclarationInParent() throws Exception {
        List<MavenProject> projects = new ArrayList<>();

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

/**
 * Verifies the version of a dependency listed in a parent's
 * dependencyManagement section is chosen over another version of the same
 * dependency, listed transitively.
 *
 */
@Deprecated
class ProjectInheritanceTest extends AbstractProjectInheritanceTestCase {

    // ----------------------------------------------------------------------

    /**
     * How the test project is set up:
     *
     * 1. dependencyManagement lists dependencies on a & b,
     *    with an exclusion on c in b.
     * 2. the child project lists a dependency on project a only
     * 3. a depends on b (which is transitive to the child project),
     *    and b depends on c.
     *

 <<<plexus.core>>> and <<<plexus.core.maven>>> realms at run-time if required.
 Plugins can state compile-time dependencies on any of the resources found in
 the core realms listed above and these dependencies will be included in the
 plugin descriptor that is generated but when running within Maven these
 resources will be filtered out. In other words these resources will not