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
configure reports according to spec:
- <reporting> section affects reports run through site and standalone
- <build> section affects reports run standalone and overrides anything already in <reporting>
- command line parameters rule all
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191298 13f79535-47bb-0310-9956-ffa450edef68