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
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
- The CloverCheckMojo still doesn't seem to work and report a coverage error when used in the simple sample. Not sure why yet
- The CloverReportMojo doesn't work as mixed plugins do not seem to be supported yet.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209751 13f79535-47bb-0310-9956-ffa450edef68
o Normalized all references to plugins to use either o.a.m.model.Plugin or o.a.m.plugin.PluginDescriptor instances
o Changed DefaultLifecycleExecutor, PluginManager, DefaultPluginManager, MavenPluginCollector, and DoxiaMojo to reflect the above
o Added mapped-plugin resolution of goal prefixes to the DefaultLifecycleExecutor
o Added caching of PluginMappingManager instance inside of MavenSession
o Modified SettingsUtils to be more resistant to null String-Lists for pluginGroups and activeProfiles during merge.
o Added checks to MavenProject.addPlugin(..) to only add if the plugin doesn't already exist in the model.
Next step is to modify installation and deployment process for plugins to publish plugins.xml repository metadata.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209677 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
simplified by removing a bunch of duplicated code in addArtifacts - no need to merge, you have the full list.
separated the original artifacts (dependency artifacts) from the resolved artifacts (getArtifacts)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191667 13f79535-47bb-0310-9956-ffa450edef68
split artifact impl from api so that dep resolution can be used independently of wagon
only the first step in making maven-artifact more useful as a public api - more changes to be made
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191634 13f79535-47bb-0310-9956-ffa450edef68
- refactor project out of MavenSession so that it can be cloned
- refactor lifecycle construction out so we can clone the existing one and pass it into a new execution
- only resolve plugins that are executed (MNG-489)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191413 13f79535-47bb-0310-9956-ffa450edef68
Vincent Siveton
John Dennis Casey
Emmanuel Venisse
Vincent Massol
Trygve Laugstol
Jason van Zyl
Brett Leslie Porter