* of the child. The general idea is to adjust inherited URLs to match the project layout (in SCM).
     *
     * <p>This calculation is only a heuristic based on our conventions.
     * In detail, the algo relies on the following assumptions: <ul>
     * <li>The parent uses aggregation and refers to the child via the modules section</li>
     * <li>The module path to the child is considered to

     * of the child. The general idea is to adjust inherited URLs to match the project layout (in SCM).
     *
     * <p>This calculation is only a heuristic based on our conventions.
     * In detail, the algo relies on the following assumptions: <ul>
     * <li>The parent uses aggregation and refers to the child via the modules section</li>
     * <li>The module path to the child is considered to

            String expectedChecksum = new String(bytes, StandardCharsets.UTF_8);

            // remove whitespaces at the end
            expectedChecksum = expectedChecksum.trim();

            // check for 'ALGO (name) = CHECKSUM' like used by openssl
            if (expectedChecksum.regionMatches(true, 0, "MD", 0, 2)
                    || expectedChecksum.regionMatches(true, 0, "SHA", 0, 3)) {

        options.addOption(Option.builder(ALSO_MAKE)
                .longOpt("also-make")
                .desc("If project list is specified, also build projects required by the list")
                .build());
        options.addOption(Option.builder(ALSO_MAKE_DEPENDENTS)
                .longOpt("also-make-dependents")
                .desc("If project list is specified, also build projects that depend on projects on the list")
                .build());

    <!--
      | MNG-6240: Plugins might depend on maven-aether-provider <= 3.3.9 before the rename to maven-resolver-provider.
      | Since backwards-compatibility was kept, Maven Core also provides this artifact.
     -->
    <exportedArtifact>org.apache.maven:maven-aether-provider</exportedArtifact>
    <exportedArtifact>org.apache.maven:maven-resolver-provider</exportedArtifact>

            }
        }

        result.setArtifactResolutionNodes(set);

        return result;
    }

    /**
     * Get the map of managed versions, removing the originating artifact if it is also in managed versions
     *
     * @param originatingArtifact artifact we are processing
     * @param managedVersions original managed versions
     */
    private ManagedVersionMap getManagedVersionsMap(

        // NOTE: Release metadata includes version information about artifacts that have been released, to allow
        // meta-versions like RELEASE and LATEST to resolve, and also to allow retrieval of the range of valid, released
        // artifacts available.
        ArtifactRepositoryPolicy policy = metadata.getPolicy(repository);

        if (!policy.isEnabled()) {

 * such as {@code project.build.sourceDirectory}.
 * <p>
 * In addition to usual getters using {@code getXxx} or {@code isXxx} suffixes, accessors
 * using {@code asXxx} or {@code toXxx} prefixes are also supported.
 */
public class ReflectionValueExtractor {
    private static final Object[] OBJECT_ARGS = new Object[0];

    /**
     * Use a WeakHashMap here, so the keys (Class objects) can be garbage collected.

     *
     * <ul>
     *   <li>If {@link #MODULES} path type is also set, then the dependency can be placed either on the
     *       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,

            </build>
        </profile>
        <profile>
            <id>generate-docs</id>
            <!--
            Generate the documentation artifacts. 
            Note: this profile is also required to be active for release
            builds due to the packaging requirements of the Central repo
            -->
            <build>
                <plugins>
                    <plugin>