plugin.setGroupId(tok[0]);
            plugin.setArtifactId(tok[1]);
            plugin.setVersion(tok[2]);
            goal = tok[3];

            // This won't be valid, but it constructs something easy to read in the error message
            for (int idx = 4; idx < tok.length; idx++) {
                goal += ":" + tok[idx];
            }
        } else if (numTokens == 3) {

                    LifecyclePhaseNotFoundException, LifecycleNotFoundException, PluginVersionResolutionException {
        // Maybe do something ?
    }

    public MavenExecutionPlan calculateExecutionPlan(
            MavenSession session, MavenProject project, List<Task> tasks, boolean setup)

- plugin dependency metadata missing
- plugin dependency metadata retrieval problem
- plugin configuration problem
- plugin execution failure due to something that is know to possibly go wrong (like compilation failure)
- plugin execution error due to something that is not expected to go wrong (the compiler executable missing)
- asking to use a plugin for which you do not have a version defined - tools to easily select versions

                            + " (" + repository.getUrl() + ")");
        }

        if (file == null) {
            // TODO throw something instead?
            return true;
        }

        Date lastCheckDate;

        if (file.exists()) {
            lastCheckDate = new Date(file.lastModified());
        } else {

    currently wrong for execution.

    <<NOTE:>> Do we want to fail when we cannot bind a mojo to the lifecycle
    because of offline/online status? That would probably indicate that the user
    was trying to do something they cannot succeed at for now...so we probably

                    result.addMissingArtifact(artifact);
                }
            } catch (ArtifactResolutionException e) {
                // This is really a wagon TransferFailedException so something went wrong after we successfully
                // retrieved the metadata.

                synchronized (result) {
                    result.addErrorArtifactException(e);
                }

 So I guess it's important to figure out what people are using properties
 files for and see if we can't incorporate it all into the POM. Or if we do
 have properties file (something I would like to avoid) say they don't
 contribute in any meaningful way to information in the POM. For example a
 properties file could be used the specify $ so it can be interpolated in

     * <pre>java -jar ${maven.repo.local}/org/apache/maven/maven-artifact/${maven.version}/maven-artifact-${maven.version}.jar "1.2.7" "1.2-SNAPSHOT"</pre>
     * command to command line. Result of given command will be something like this:
     * <pre>
     * Display parameters as parsed by Maven (in canonical form) and comparison result:
     * 1. 1.2.7 == 1.2.7
     *    1.2.7 &gt; 1.2-SNAPSHOT
     * 2. 1.2-SNAPSHOT == 1.2-snapshot

    }

    /**
     * Build an ArtifactRepository object.
     *
     * @param id
     * @return
     */
    private ArtifactRepository getRepo(String id) {
        return getRepo(id, "http://something");
    }

    @Test
    void testDefaultWagonManager() throws Exception {
        assertWagon("a");

        assertWagon("b");

        assertWagon("c");

        assertWagon("string");

  |
  | 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)
  |