Submitted by: Edwin Punzalan
Reviewed by: Brett Porter
applied FAQ update with some modifications for out of date information since the issue was filed.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219436 13f79535-47bb-0310-9956-ffa450edef68
o Added ResolutionGroup class which contains a set of artifacts and a list of repositories to resolve them.
o Made the ResolutionNode a standalone class, and added the remote repositories to it
o Changed ArtifactMetadataSource.retrieve(..) to return ResolutionGroup rather than Set, in order to help keep track of the repositories which should be used to resolve the retrieved artifacts.
We need some tests for this...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219276 13f79535-47bb-0310-9956-ffa450edef68
To use the new artifact map for either the project or the current plugin from your mojo, simply use one of the following expressions:
${plugin.artifactMap}
${project.artifactMap}
The artifacts in these maps are keyed using org.apache.maven.artifact.ArtifactUtils.versionlessKey( String groupId, String artifactId ) (found in the maven-artifact project).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219234 13f79535-47bb-0310-9956-ffa450edef68
o Added four command-line options:
--check-plugin-updates is a synonym for --update-plugins
--no-plugin-registry turns off usage of plugin-registry.xml for plugin version resolution for the current build.
--check-plugin-latest turns on usage of LATEST metadata for plugin version resolution for the current build.
--no-plugin-latest turns off usage of LATEST metadata for plugin version resolution for the current build.
o Added settings.xml configuration <usePluginRegistry>true|false</usePluginRegistry> to en/disable the use of plugin-registry.xml for plugin version resolution. The default value is true, to use the plugin-registry.xml.
o Added plugin-registry.xml configuration <checkLatest>true|false</checkLatest> to en/disable the use of LATEST metadata when resolving plugin versions. The default value is false, or do not use LATEST.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@219089 13f79535-47bb-0310-9956-ffa450edef68
One change:
o Applied lifecycle mapping patch to a new file in src/main/resources of the ear plugin project, to create META-INF/plexus/components.xml with the custom lifecycle mapping.
This plugin needs an integration test.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@216275 13f79535-47bb-0310-9956-ffa450edef68
o Implemented plan from my comments on MNG-576 for looking up lifecycle mappings within plugins.
o Fixed subtle bug in DefaultWagonManager for verifying checksums, where the destination file was being used to verify the checksum rather than the recently download temp destination.
o Fixed the DefaultRepositoryMetadataManager.resolve(..) method to allow the locally-installed metadata to be used if it is newer than the one resolved from the repository.
o Moved the lifecycle mappings for the EJB and WAR plugins out to META-INF/plexus/components.xml in the respective plugin's src/main/resources directory. it0016 and it0017 still pass.
o Changed the distributionManagement repository for maven-plugins/pom.xml to have id of 'central-plugins' and then added a normal artifact repository definition for central-plugins to that pom, to allow locally-installed repository metadata for the plugins to be put in the right place (and these builds should have access to the central plugin repo anyway).
o Changed the DefaultPluginMappingBuilder to only warn when plugins.xml for a particular plugin group is missing.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@216273 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
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
Brett Leslie Porter
Emmanuel Venisse
John Dennis Casey
Vincent Siveton
Jason van Zyl
Vincent Massol