<type>DOM</type> <!-- DOM for Maven 2.0.9/2.3.3 -->
          <description>
            Toolchain identification information, which will be matched against project requirements.
            &lt;p>Actual content structure is completely open: each toolchain type will define its own format and
            semantics.
            &lt;p>This is generally a properties format: {@code &lt;name&gt;value&lt;/name&gt;} with predefined

      pre-calculated execution plan that stays the same during the execution.

      If deciding to add mutable state to this class, it should be at least considered to
      separate this into a separate mutable structure.

    */

    private final List<ExecutionPlanItem> planItem;

    private final Map<String, ExecutionPlanItem> lastMojoExecutionForAllPhases;

    final List<String> phasesInExecutionPlan;

       <name>theme</name>
       <value>classic</value>
     </parameter>
   </parameters>
  </plugin>
</plugins>
+-----+

Unified source directory

 Unified source directory structure that is analogous to the repository
 itself. This way locations of intermediary artifacts of a build would be
 in a known location. This would also help with developer setup i.e. getting

// I want to set up a local/remote repositories for testing but I don't want to have
// to change them when I change the layout of the repositories. So I want to generate
// the structure I want to test by using the artifact handler manager which dictates
// the layout used for a particular artifact type.

/**
 */
@Deprecated
class ArtifactResolverTest extends AbstractArtifactComponentTestCase {

import static org.mockito.ArgumentMatchers.anyList;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

class DefaultGraphBuilderTest {
    /*
    The multi-module structure in this project is displayed as follows:

    module-parent
    └─── module-independent     (without parent declaration)
         module-a
         module-b               (depends on module-a)
         module-c

            buffer.append(" instead of ").append(parent.getGroupId()).append(':');
            buffer.append(parent.getArtifactId()).append(", please verify your project structure");

            problems.setSource(childModel);
            problems.add(Severity.WARNING, ModelProblem.Version.BASE, buffer.toString(), parent.getLocation(""));
            return null;
        }

      </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>
            <![CDATA[
    /**

    String SELF_COMBINATION_MERGE = "merge";

    String SELF_COMBINATION_REMOVE = "remove";

    /**
     * In case of complex XML structures, combining can be done based on id.
     */
    String ID_COMBINATION_MODE_ATTRIBUTE = "combine.id";

    /**
     * In case of complex XML structures, combining can be done based on keys.
     * This is a comma separated list of attribute names.
     */