* This should be the resulting ordering of plugins after merging:
     * <p>
     * Given:
     * <pre>
     * parent: X -&gt; A -&gt; B -&gt; D -&gt; E
     * child: Y -&gt; A -&gt; C -&gt; D -&gt; F
     * </pre>
     * Result:
     * <pre>
     * X -&gt; Y -&gt; A -&gt; B -&gt; C -&gt; D -&gt; E -&gt; F
     * </pre>
     */
    public static void mergePluginLists(

            <p>Actual content structure is completely open: each toolchain type will define its own format and
            semantics.
            <p>This is generally a properties format: {@code <name>value</name>} with predefined
            properties names.
          </description>
        </field>
        <field>
          <name>provides</name>
          <version>1.1.0+</version>

     * configurations, as in the case where you want to use the artifact's final name as a parameter. In this case, you
     * want the user to modify <code>&lt;build&gt;&lt;finalName/&gt;&lt;/build&gt;</code> rather than specifying a value
     * for finalName directly in the plugin configuration section. It is also useful to ensure that - for example - a

    }

    // tests ------------------------------------------------------------------

    /**
     * Tests that <code>a:2.0</code> wins in the scenario:
     * <pre>
     * a:1.0
     * b:1.0 -&gt; a:2.0
     * </pre>
     */
    @Test
    void testDepth() {
        ResolutionNode a1n = createResolutionNode(a1);
        ResolutionNode b1n = createResolutionNode(b1);

    }

    // tests ------------------------------------------------------------------

    /**
     * Tests that <code>a:2.0</code> wins in the scenario:
     * <pre>
     * a:1.0
     * b:1.0 -&gt; a:2.0
     * </pre>
     */
    @Test
    void testDepth() {
        ResolutionNode a1n = createResolutionNode(a1);
        ResolutionNode b1n = createResolutionNode(b1);

     */
    String findTool(String toolName);

    /**
     * Let the toolchain decide if it matches requirements defined
     * in the toolchain plugin configuration.
     * @param requirements Map<String, String> key value pair, may not be {@code null}
     * @return {@code true} if the requirements match, otherwise {@code false}
     */
    boolean matchesRequirements(Map<String, String> requirements);

    }

    /**
     * Test <a href="https://issues.apache.org/jira/browse/MNG-5568">MNG-5568</a> edge case
     * which was showing transitive inconsistency: since A &gt; B and B &gt; C then we should have A &gt; C
     * otherwise sorting a list of ComparableVersions() will in some cases throw runtime exception;
     * see Netbeans issues <a href="https://netbeans.org/bugzilla/show_bug.cgi?id=240845">240845</a> and

public interface ToolchainPrivate extends Toolchain {

    /**
     * Let the toolchain decide if it matches requirements defined
     * in the toolchain plugin configuration.
     * @param requirements Map<String, String> key value pair, may not be {@code null}
     * @return {@code true} if the requirements match, otherwise {@code false}
     */
    boolean matchesRequirements(Map<String, String> requirements);

    /**
     *

            plugin configurations, as in the case where you want to use the artifact's final name as a parameter. In
            this case, you want the user to modify {@code <build><finalName/></build>} rather
            than specifying a value for finalName directly in the plugin configuration section. It is also useful to

  </description>

  <properties>
    <!-- That's the property containing escaped XML markup -->
    <xmlMarkup>&lt;?xml version='1.0'?&gt;Tom&amp;Jerry</xmlMarkup>
    <!-- That's a property where the above property will be resolved -->
    <xmlTest>${xmlMarkup}</xmlTest>
  </properties>