for (Plugin plugin : plugins) {
                Object key = plugin.getKey();
                Plugin first = normalized.get(key);
                if (first != null) {
                    plugin = merger.mergePlugin(plugin, first);
                }
                normalized.put(key, plugin);
            }

            if (plugins.size() != normalized.size()) {

     * between any two nodes, if multiple exists. Uses scope relationships, defined
     * in <code>ArtifactScopeEnum</code>
     *
     * @param graph the "dirty" graph to be simplified via conflict resolution
     * @param scope scope for which the graph should be resolved
     *
     * @return resulting "clean" graph for the specified scope
     *
     * @since 3.0
     */

        for (Lifecycle lifecycle : getLifeCycles()) {
            logger.debug("Lifecycle {}", lifecycle);

            for (String phase : lifecycle.getPhases()) {
                // The first definition wins.
                if (!phaseToLifecycleMap.containsKey(phase)) {
                    phaseToLifecycleMap.put(phase, lifecycle);
                } else if (logger.isWarnEnabled()) {

    static {
        // Those two public constants are initialized here, as they need all the private constants
        // above to be initialized first, but the code style imposes the public constants to be
        // defined above the private ones...
        OS_FAMILY = getOsFamily();
        IS_WINDOWS = isFamily(FAMILY_WINDOWS);
    }

    private Os() {}

        /*
         * NOTE: "invoker:install" vs "appassembler:assemble": Both mojos use the artifact installer to put an artifact
         * into a repository. In the first case, the result needs to be a proper local repository that one can use for
         * local artifact resolution. In the second case, the result needs to precisely obey the path information of the

        // POMs are always returned from the file system
        if ("pom".equals(artifact.getExtension())) {
            return project.getFile();
        }

        // First check in the project local repository
        File packagedArtifactFile = findInProjectLocalRepository(artifact);
        if (packagedArtifactFile != null
                && packagedArtifactFile.exists()

                    pluginDescriptor.getPlugin(),
                    "The plugin " + pluginDescriptor.getId() + " has unmet prerequisites: " + messages,
                    prerequisiteExceptions.get(0));
            // the first exception is added as cause, all other ones as suppressed exceptions
            prerequisiteExceptions.stream().skip(1).forEach(pie::addSuppressed);
            throw pie;
        }
    }

    @Override

          <description>
            The relative path of the parent {@code pom.xml} file within the checkout.
            If not specified, it defaults to {@code ../pom.xml}.
            Maven looks for the parent POM first in this location on
            the filesystem, then the local repository, and lastly in the remote repo.
            {@code relativePath} allows you to select a different location,

both(Matcher<? super LHS> matcher) { return new CombinableBothMatche<LHS>(matcher); } public static final class CombinableBothMatche<X> { private final Matcher<? super X> first; public CombinableBothMatche(Matcher<? super X> matcher) { this.first = matcher; } public CombinableMatcher<X> and(Matcher<? super X> other) { return new CombinableMatcher<X>(first).and(other); } } /** * Creates a matcher that matches when either of the specified matchers match the examined object. * <p/> * For example: * <pre>assertThat("fan",...

       where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue.
 - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`.
       Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message.
 - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.