<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
    }

          </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>

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);

 * 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;

            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>

        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.
     *

- I could make an annotation that marked another class as its plugin discoverer, I could just add it to
  the component descriptor and when it's loaded we can add the discoverer, that would be simpler. I could
  also do this with the lister as well
i'l
// 1 the metadata -> model plugin/mojo descriptor
// 2 tools for doing the mapping
// 3 the component model -> interfaces for the plugin

// The plugin manager should load up a directory structure of plugins.