o If the metadata version is still in the plugin artifact after it's resolved, then simply return null and allow the plugin version resolution process to fail.
o Added a new mojo to update the plugin registry (if it's enabled) with newly installed versions of plugins.
o Added comments to maven-settings and maven-plugin-parameter-documenter poms marking the packageWithVersion config as deprecated pending modello alpha-5
o Cleaned up it0013 and it0020 to work with the new resolution (point one above).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@293520 13f79535-47bb-0310-9956-ffa450edef68
o Adding cli-options.txt for three ITs that failed when I cleaned out the local repo
o Fixing the setFile(..) method of ActiveProjectArtifact (hopefully) for Emmanuel's continuum build problem...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@226426 13f79535-47bb-0310-9956-ffa450edef68
o Added lines in it0015 and it0020 prebuild-hooks to remove the IT plugins before executing, to avoid weird, intermittent Zip exceptions.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@226330 13f79535-47bb-0310-9956-ffa450edef68
Now, in order to build a maven plugin, you need two things:
1. a repository defined in distributionManagment
2. a repository defined in <repositories/> which has the same id as the one in distributionManagement.
This is necessary, since in most cases SSH will be used in the distributionManagement definition for uploading the plugin...which means that the download of the existing plugins.xml file might not be available for users trying to run an install. SSH requires authentication information, and users (particularly those running the bootstrap) might not have this auth info.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@216013 13f79535-47bb-0310-9956-ffa450edef68
Brett Leslie Porter
John Dennis Casey
Emmanuel Venisse