*
     * @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)".
     *

        assertEquals(
                "2.0.6",
                pom.getValue(
                        "build/plugins[1]/executions[1]/configuration[1]/rules[1]/requireMavenVersion[1]/version"));
        assertEquals(
                "[1.4,)",
                pom.getValue("build/plugins[1]/executions[1]/configuration[1]/rules[1]/requireJavaVersion[1]/version"));
    }

  |   what is allowed in the field.
  |
  | o validators: there could be several levels of validation. Simple type validation could
  |   be done with a regex, but we need inter-field validation and rules which could be
  |   dealt with by something like drools.
  |
  | o i18n: would be good to be able to have names/descriptions/specifications
  |   in as many languages as possible. (see MNG-3626)
  |

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

    String BOM = "bom";

    /**
     * Artifact type name for a JAR file that can be placed either on the class-path or on the module-path.
     * The path (classes or modules) is chosen by the plugin, possibly using heuristic rules.
     * This is the behavior of Maven 3.
     */
    String JAR = "jar";

    /**
     * Artifact type name for a fat-JAR file that can be only on the class-path.

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

                                    + "For such purposes you should use the maven-enforcer-plugin. "
                                    + "See https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html",
                            mavenProject.getId());
                }
            }
        }
    }

    /**

     *       class-path or on the module-path, but only one of those. The choice is up to the plugin,
     *       possibly using heuristic rules (Maven 3 behavior).</li>
     *   <li>If a {@link #patchModule(String)} is also set and the main JAR file is placed on the module-path,

     * to the module-path if it contains a {@code module-info.class}, or to the class-path otherwise.
     * For the test output directory, the rules are more complex and are governed by the fact that
     * Java does not accept the placement of two modules of the same name on the module-path.

     * For example, an artifact of type {@value org.apache.maven.api.Type#JAR} can be placed
     * either on the class-path or on the module-path. The project needs to make a choice
     * (possibly using heuristic rules), then to add the dependency in only one of the options
     * identified by {@link PathType}.</p>
     *
     * @return file paths to place on the different tool options
     */
    @Nonnull