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
This fixed a couple of bugs along the way.
One change that this has brought to bear from the document is you now must specify a goal for it to be bound to the LC
(see it0008)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191285 13f79535-47bb-0310-9956-ffa450edef68
o Changed <reports/> in the Model to <reporting/>, to accommodate the <reports/> inside of <reportSet/>.
o Changed the report-plugin class <plugins/> inside of <report[ing]/> to <reporters/>, which means using a new class called Reporter (this is meant to be a Plugin-like model for reports, with reportSets rather than executions...)
o Changed the MavenProject to reflect these two model changes
o Added support to the inheritance assembler to perform deep inheritance of the reporting model (complete with calculations based on the <inherit/> attributes on Reporter and ReportSet).
o Updated DoxiaMojo, Pom, and DefaultPluginVersionManager to reflect the new model classes and MavenProject methods.
This is only round one of the changes for this issue. The next step is to start binding report configuration to the plugin manager via the lifecycle executor (it will traverse the reporting section, and verifyPlugin() to enable direct calls to the report's mojo).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@191239 13f79535-47bb-0310-9956-ffa450edef68