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
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 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 Added component descriptor for the MavenPluginMappingBuilder
o Added a new ComponentDiscoveryListener implementation to factor the DefaultPluginManager out of the plexus.xml for maven-core...the DefaultPluginManager now delegates to this component for plugin registration/lookup/etc. and has proper component requirements.
o Moved the DefaultPluginManager component declaration into components.xml, and added a component definition for MavenPluginCollector to plexus.xml in maven-core
Next step is to get rid of the old pluginKey junk, and start using o.a.m.Plugin instances to hold g🅰️v info for all plugins in the system...this will make the interface cleaner and remove the need to concat/parse the plugin identity. Then, I'll add the mapped-plugin lookup functionality to the lifecycle executor.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209563 13f79535-47bb-0310-9956-ffa450edef68
o Added maven-plugin-mapping project to handle repository metadata that contains prefix-to-artifactId mappings for groups of plugins
o Added builder classes for plugin mappings
o Modified maven-artifact and maven-artifact-manager to handle the concept of repository metadata in addition to artifact metadata.
o Added pluginGroups section to settings.xml, new code to merge these lists of plugin groups, and a unit test to ensure that this merge is taking place properly.
o Added maven-plugin-mapping to dependencies of maven-core, along with the list of builds to be performed by mboot.
Should be ready to incorporate plugin mapping consultation into the lifecycle executor and the deploy mojo...
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@209550 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
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@191664 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
o During addPlugin() only the plugin's artifact is resolved/added...just enough to get the plugin container to discover the pluginDescriptor.
o During getConfiguredMojo(), the rest of the plugin's artifacts will be transitively resolved and added to the plugin container (if this hasn't already been done). The deciding factor for attempting to complete the plugin container's artifact list is whether the only artifact in the pluginDescriptor's artifact list is the plugin artifact itself. If that makes sense.
It's a bit of black magic, but I think it'll work unless/until we find something more elegant. I'm abusing the container a little bit here, so it might be sensitive to plexus changes in future.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191582 13f79535-47bb-0310-9956-ffa450edef68
o Adding extraction of mojo-specific configuration from the merged config for the plugin
o Warning at the DEBUG log-level for unused plugin configuration during the extraction process above
o Added integration test it0028 to test with unused plugin configuration present.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191552 13f79535-47bb-0310-9956-ffa450edef68
o Added checksumPolicy to artifact repository construction, which meant changing all the places where the factory was called.
o Added two command-line switches (-C=strict-checksum-checking, -c=lax-checksum-checking, or warning)
o Added checksum policy to all repository definitions (profiles.mdo, settings.mdo, maven.mdo)
o Changed the maven-artifact-ant stuff to use a Repository definition with checksumPolicy added to it
NOTE: I just realized that I haven't touched the inheritance/conversion of repository stuff from profiles/settings.xml to the model. I'll do this, and commit the additional changes.
Currently, the default checksum policy is to warn, since there are still bad checksums out there that prevent bootstrapping. Once we chase these down, we can change to default-strict checking. When verifying checksums, SHA-1 is attempted first, with MD5 acting as a backup verification method. If the checksum verification fails legitimately (not related to the process of retrieving/reading the checksum file), then the verification process is repeated ONCE ONLY.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191536 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
John Dennis Casey
Emmanuel Venisse
Trygve Laugstol
Brett Leslie Porter