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
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
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
Added specified stop-gap patch for issue: MNG-473 (affects settings-builder and registry-builder)
Today I've made the following progress on this so far:
- Added a new project, called maven-plugin-registry, to house the model for this new file.
- Developed/debugged/tested PluginVersionManager/DefaultPluginVersionManager to isolate the plugin-version checks/management code away from the PluginManager
- Added interactiveMode (<interactiveMode>true|false</interactiveMode> directly under the root element of settings.xml, or -B short CLI option or --batch-mode CLI option, where the CLI options turn OFF interactiveMode). This will allow things like the maven-plugins build to register new plugins (and, for now, new versions of plugins) automatically.
- Added user input handler for when interactiveMode = true, to get a yes/no on whether to use the discovered version over the installed version and/or no version at all. If there is no installed version, and the user selects 'n', then the discovered version is used FOR THAT SESSION ONLY, and won't be recorded in the registry.
- Added checks/recording rejected versions against the registry, before attempting to use the discovered version.
Pending:
- Still need to add update-policies, to determine two things:
1. how often to check for updates
2. what to do when updates are found (autoUpdate, etc.)
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190854 13f79535-47bb-0310-9956-ffa450edef68
reverse the reference. DoxiaMojo depends on maven-core instead of maven-core depending on the reporting api + doxia
This is not a great solution, but it gets us closer. It is currently not possible, as before, to get the correct set of reports as they are all loaded into the one container and then everything found is returned.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@188690 13f79535-47bb-0310-9956-ffa450edef68
o Moved marmalade support dependencies out of maven-core, since they can be supported on demand now
o changed the ordering of the ant and assembly plugins, to show that the classloader (plugin param) bug is fixed.
o added a method in PluginDescriptor which is similar to o.a.m.model.Plugin.getId() (I think that's the method; it's the one that results in a key of 'g:a')
o moved wagon-ssh dependency into maven-core, since there is a new issue related to nested containers and wagons which are introduced as plugin dependencies. This should be solved using a mechanism similar to plugin-manager for wagon-manager impl in future anyway
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@187639 13f79535-47bb-0310-9956-ffa450edef68
Still need to clean up ~/maven2/lib and some large dependencies from marmalade that
shouldn't be needed in general - but down to about a 3Mb repository.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163775 13f79535-47bb-0310-9956-ffa450edef68
This supports a change to a simpler local configuration file (~/.m2/settings.xml by default), which has the general format of:
<settings>
<profiles>
<profile>
<active>true</active> <!-- not needed if this is the only profile -->
<localRepository>/path/to/repo</localRepository>
</profile>
.
.
.
</profiles>
<servers>
<server>
<id>myserver</id>
<username>me</username>
<password>mypass</password>
<privateKey>/path/to/key</privateKey>
<passphrase>key-passphrase</passphrase>
</server>
.
.
.
</servers>
<proxies>
<proxy>
<active>true</active> <!-- not needed if this is the only proxy -->
.
.
.
</proxy>
.
.
.
</proxies>
</settings>
o Added special parameter named '#settings' which simply injects the current MavenSettings from the MavenSession into the request parameters.
o Adjusted the it-verifier and mboot2 accordingly.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163578 13f79535-47bb-0310-9956-ffa450edef68
plexus runtime generator produces so that i may attempt to use it
some point in the near future
o flipped back to 0.9-S of wagon until I run this on beaver to
verify
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163110 13f79535-47bb-0310-9956-ffa450edef68
o Removed PluginDownloadPhase, since plugin resolution/download has to be a part of the prereq and pre/postGoal resolution, too
o Changed DefaultMaven to execute the session lifecycle, and the component wiring to likewise wire the DefaultMaven with a session lifecycle manager
o Removed the org.apache.maven.decoration package and its contents, since this is all in the model now
o Fixed the GoalResolutionPhase to verify each goal's plugin in turn as it resolves prereqs, preGoals and postGoals
o Fixed the GoalResolutionPhaseTest to work with the new resolution model
o Added a new createGoalExecutionContext to the MavenTestCase base class, to allow me to inject a MavenProject directly rather than a pom file
o Fixed the MavenLifecycleManagerTest to only expect 4 lifecycle phases, now than the plugin resolution and goal decoration phases are obsoleted
o All builds on local machine, but will depend on plexus-0.17.jar/pom and plexus-artifact-container-1.0-alpha-1.jar/pom to build on beaver
o I uploaded plexus-artifact-container-1.0-alpha-1.jar to ${plexus.home}/dist, but cannot upload POMs due to priveleges problem in poms dir.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163007 13f79535-47bb-0310-9956-ffa450edef68
o Changed the embedder/container used to be the new artifact-aware container (plexus-artifact-container-1.0-alpha-1)
o Added new dependency to maven-core for artifact-container.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@163006 13f79535-47bb-0310-9956-ffa450edef68
John Dennis Casey
Brett Leslie Porter
Emmanuel Venisse
Jason van Zyl