1.0-alpha-5-SNAPSHOT for all so they're all the same.
o Updated modello plugin invocations in all poms to by adding execution elements
and fixing goals section to get rid of deprecated notation.
o Removed dependency on modello-core in maven-plugin-tools; it seems it
was there because maven-plugin-tools-java used StringUtils from modello -
changed that to use the plexus-utils version.
o Reversed commons-cli version back to 1.0 (brett asked me to, a few days back).
o Updated all models to use fully qualified classnames - do not assume
java.util.* is included! (it won't be anymore from modello
1.0-alpha-5-SNAPSHOT onward).
o Added some <?xml processing instructions to some models that didn't have them
- vim now recognizes these files as XML (so I get syntax highlighting :))
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@280539 13f79535-47bb-0310-9956-ffa450edef68
under dependencyManagement of m2 and maven-plugins, and removed
versions in all poms having either as a parent.
Used version 1.0.2-SNAPSHOT for plexus-utils as that was used in maven-core
and is not overridable.
o Bumped maven-archiver version to 2.0-beta-1-SNAPSHOT for maven-ear-plugin
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@227084 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
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
Brett Leslie Porter
Kenney Westerhof
Emmanuel Venisse
John Dennis Casey
Jason van Zyl