}

    // TODO let the scope handler deal with this
    private static boolean isCompilePathElement(final String scope) {
        return Artifact.SCOPE_COMPILE.equals(scope)
                || Artifact.SCOPE_PROVIDED.equals(scope)
                || Artifact.SCOPE_SYSTEM.equals(scope);
    }

    // TODO let the scope handler deal with this

            // even before the arguments from the command line are parsed.  Any exception
            // that would happen here should cause the build to fail at a later stage
            // (when actually parsing the POM) and will lead to a better exception being
            // displayed to the user, so just bail out and return false.
        }
        return false;
    }

         * unique within a single POM. Upon multiple declarations, 2.x just kept the last one but retained the order of
         * the first occurrence. So when we're in lenient/compat mode, we have to deal with such broken POMs and mimic
         * the way 2.x works. When we're in strict mode, the removal of duplicates just saves other merging steps from
         * aftereffects and bogus error messages.
         */

        of dependencies.</description>
      <version>3.0.0+</version>
      <fields>
        <field>
          <name>name</name>
          <version>3.0.0+</version>
          <description>The full legal name of the license.</description>
          <type>String</type>
        </field>
        <field>
          <name>url</name>
          <version>3.0.0+</version>

            //
            // We need an executor that will not block.
            // We can't use work stealing, as we are building a graph
            // and this could lead to cycles where a thread waits for
            // a task to finish, then execute another one which waits
            // for the initial task...
            // In order to work around that problem, we override the

Offline Mode Design

* UPDATE: 18-April-2005

  We cannot take the approach outlined below of detecting which remote
  repositories are "really" offline, since offline mode is more of a behavior,
  and this will lead to counter-intuitive results. A different feature may exist
  unimplemented, which is to detect when the network is down and provide better
  feedback for that case. However, when offline mode is declared, nothing

        // We have metadata retrieval problems, or there are cycles that have been detected
        // so we give this back to the calling code and let them deal with this information
        // appropriately.

        if (result.hasMetadataResolutionExceptions()
                || result.hasVersionRangeViolations()
                || result.hasCircularDependencyExceptions()) {

                "BEER",
                INSTALL.getPhase());

        // The two phases below are really for future expansion, some would say they lack a drink
        // The point being that they do not really have to match the "real" stuff,
        List<String> stubCleanCycle = Arrays.asList(PRE_CLEAN.getPhase(), CLEAN.getPhase(), POST_CLEAN.getPhase());

        List<String> stubSiteCycle =