import org.apache.maven.model.Plugin;
import org.apache.maven.plugin.MojoExecution;
import org.apache.maven.plugin.descriptor.MojoDescriptor;

// TODO lifecycles being executed
// TODO what runs in each phase
// TODO plugins that need downloading
// TODO project dependencies that need downloading
// TODO unfortunately the plugins need to be downloaded in order to get the plugin.xml file. need to externalize this

          <type>String</type>
          <description>Specifies that this profile will be activated based on the project's packaging.</description>
        </field>
        <!--
        This could be included once we teach Maven to deal with multiple versions of the model
        <field>
          <name>custom</name>
          <version>4.1.0+</version>
          <description>Describes a custom profile activation trigger, brought in via build

     *       at a deep intentionally restricted to one level, then builds a map of module names found
     *       in the descriptor of each sub-directory.</li>
     * </ul>
     *
     * Otherwise if the given path is a JAR file, then there is a choice:
     * <ul>
     *   <li>If a {@code module-info.class} file is found in the root directory or in a

     */
    @Nonnull
    Map<String, String> getSystemProperties();

    /**
     * Each invocation computes a new map of effective properties. To be used in interpolation.
     * <p>
     * Effective properties are computed from system, user and optionally project properties, layered with
     * defined precedence onto each other to achieve proper precedence. Precedence is defined as:
     * <ul>

        assertEquals(0, c2.compareTo(c1), "expected " + v2 + " == " + v1);
    }

    private void checkVersionsArrayEqual(String[] array) {
        // compare against each other (including itself)
        for (int i = 0; i < array.length; ++i)
            for (int j = i; j < array.length; ++j) checkVersionsEqual(array[i], array[j]);
    }

                "<plugin-in-inactive-only>Inactive only ||${project.basedir}||</plugin-in-inactive-only>");
    }

    // Some better conventions for the test poms needs to be created and each of these tests
    // that represent a verification of a specification item needs to be a couple lines at most.
    // The expressions help a lot, but we need a clean to pick up a directory of POMs, automatically load

a) Subject to the terms of this Agreement, each Contributor hereby grants
Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce,
prepare derivative works of, publicly display, publicly perform, distribute
and sublicense the Contribution of such Contributor, if any, and such derivative
works, in source code and object code form.

b) Subject to the terms of this Agreement, each Contributor hereby grants

/**
 * A test which demonstrates maven's recursive inheritance where
 * a distinct value is taken from each parent contributing to
 * the final model of the project being assembled. There is no
 * overriding going on amongst the models being used in this test:
 * each model in the lineage is providing a value that is not present
 * anywhere else in the lineage. We are just making sure that values

      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,

       for the change (usually before you start working on it).  Trivial changes like typos do not
       require a JIRA issue. Your pull request should address just this issue, without
       pulling in other changes.
 - [ ] Each commit in the pull request should have a meaningful subject line and body.
 - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`,
       where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue.