*
     * @param version the version string to parse, must not be {@code null}
     * @return the parsed version, never {@code null}
     * @throws VersionParserException if the string violates the syntax rules of this scheme
     */
    @Nonnull
    Version parseVersion(@Nonnull String version);

    /**
     * Parses the specified version range specification, for example "[1.0,2.0)".
     *

                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <id>enforce</id>
                        <configuration>
                            <rules>
                                <bannedDependencies>
                                    <excludes>
                                        <exclude>commons-logging:*</exclude>
                                    </excludes>

     *
     * @param version the version string to parse, must not be {@code null}
     * @return the parsed version, never {@code null}
     * @throws VersionParserException if the string violates the syntax rules of this scheme
     * @see org.apache.maven.api.Session#parseVersion(String)
     */
    @Nonnull
    Version parseVersion(@Nonnull String version);

    /**

     * and no heuristic rule will be involved.
     *
     * <p>It is nevertheless common to specify two or more types of path. For example,
     * a Java library may be compatible with either the class-path or the module-path,
     * and the user may have provided no instruction about which type to use. In such
     * case, the plugin may apply rules for choosing a path. See for example

/**
 * Filter to only retain objects in the given scope or better. This implementation allows the accumulation of multiple
 * scopes and their associated implied scopes, so that the user can filter apply a series of implication rules in a
 * single step. This should be a more efficient implementation of multiple standard {@link ScopeArtifactFilter}
 * instances ORed together.
 *
 */

  <artifactId>parent</artifactId>
  <version>0.1</version>
  <packaging>pom</packaging>

  <name>Maven Integration Test :: MNG-4415</name>
  <description>
    Test that merging of plugins during inheritance follows these rules regarding ordering:
     parent: X ->      A -> B ->      D -> E
     child:       Y -> A ->      C -> D ->      F
     result: X -> Y -> A -> B -> C -> D -> E -> F
  </description>

  <build>
    <plugins>

  <artifactId>test</artifactId>
  <version>0.1</version>

  <name>Maven Integration Test :: MNG-4415</name>
  <description>
    Test that merging of plugins during inheritance follows these rules regarding ordering:
     parent: X ->      A -> B ->      D -> E
     child:       Y -> A ->      C -> D ->      F
     result: X -> Y -> A -> B -> C -> D -> E -> F
  </description>

  <build>
    <plugins>

            </goals>
            <configuration>
              <rules>
                <requireMavenVersion>
                  <version>2.0.6</version>
                </requireMavenVersion>
                <requireJavaVersion>
                  <version>[1.4,)</version>
                </requireJavaVersion>
              </rules>
            </configuration>
          </execution>
        </executions>

        }
        return info;
    }

    /**
     * Returns {@link JavaPathType#MODULES} if the given JAR file or output directory is modular.
     * This is used in heuristic rules for deciding whether to place a dependency on the class-path
     * or on the module-path when the {@code "jar"} artifact type is used.
     */
    private PathType getPathType(Path path) throws IOException {

  <artifactId>test</artifactId>
  <version>0.1</version>

  <name>Maven Integration Test :: MNG-4416</name>
  <description>
    Test that merging of plugins during profile injection follows these rules regarding ordering:
     model:   X ->      A -> B ->      D -> E
     profile:      Y -> A ->      C -> D ->      F
     result:  X -> Y -> A -> B -> C -> D -> E -> F
  </description>

  <build>
    <plugins>