MNG-511
MNG-513
Working on:
MNG-449
o Added code to stop the version manager from prompting the user for unregistered plugins; it will simply register them with the resolved version.
o Added failover fourth plugin-version resolution option, which is a plugin-specific artifact metadata called LATEST.version.txt, and will be published with each install/deployment
o Added MavenProject.get/setArtifact(..) to handle a single artifact instance for a project (allows injection of artifact metadata without having to handle it all within the install/deploy mojos).
o Changed plugin-version resolution to only use MavenMetadataSource rather than resolving the whole plugin artifact.
o Changed the install and deploy mojos to only use ${project.artifact} rather than constructing their own, so they can take advantage of metadata added elsewhere in the build.
o Factored the "RELEASE".equals(..) check in the DefaultRepositoryLayout to use new metadata method storedInArtifactDirectory() instead, since RELEASE and LATEST both share this characteristic.
NOTE: I'm not going to resolve MNG-449 yet, because I'm not sure what else Brett had in mind related to the plugin-development-without-release use case...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@215919 13f79535-47bb-0310-9956-ffa450edef68
Added new mojos to the plugin-plugin that will update the plugins.xml mapping metadata in the plugin's group on the distribution repository.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@210153 13f79535-47bb-0310-9956-ffa450edef68
o Pressing [ENTER] at a plugin update prompt should result in the plugin being registered, as indicated by the prompt.
o Use CLI switch '--no-plugin-updates' to suppress usage of the plugin registry
o Use CLI switch '--update-plugins' to force updated/resolved plugin versions to be registered
o Neither of these has a short CLI option, since we're starting to run out of sensible char options for these types of things.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@193082 13f79535-47bb-0310-9956-ffa450edef68
Still need to clean up ~/maven2/lib and some large dependencies from marmalade that
shouldn't be needed in general - but down to about a 3Mb repository.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163775 13f79535-47bb-0310-9956-ffa450edef68
change type of maven plugins to "maven-plugin" instead of plugin.
This should allow other products to have different plugin types, if necessary.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163562 13f79535-47bb-0310-9956-ffa450edef68
o Fixed problems with plugin-plugin (had to do with refactored plugin-tools stuff)
o Added marmalade-mojo support, although without an integration test (verified it doesn't get in the way of 'normal' functionality, though)
o Added code in mboot2 to copy marmalade-mojo support libs to ${maven.home}/lib
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163405 13f79535-47bb-0310-9956-ffa450edef68
o Tested with java mojos, mboot to verify nothing broken by refactor.
o TODO: Add marmalade support tests...currently only java-mojos are supported in mboot2, so this isn't going to interrupt things.
o TODO: Once marmalade support is tested, add to the list of artifacts built by mboot2.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163369 13f79535-47bb-0310-9956-ffa450edef68
this is not the way i want the installing mechanism to work (i.e. copying
the same class around ...) but folks want to install plugins so i'll just
pop this in for now.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@162997 13f79535-47bb-0310-9956-ffa450edef68
Vincent Siveton
Brett Leslie Porter
Stephane Nicoll
John Dennis Casey
Emmanuel Venisse
Jason van Zyl
Trygve Laugstol
Michal Maczka