need to be able to dynamically register providers for wagon and scm

This issue should be a breeze once the Plexus one is done.

working on this in tandem with multiple plexus.xml support, since this is the most compelling use case.

This issue is blocked by the same problem which caused problems with the assembly plugin, namely that class realms are getting mixed up. One plugin loads a component, and that component stays in the container even after that plugin is finished executing. Then, a second plugin comes along with a requirement on the same (pre-loaded this time) component. This time, the container uses the component defined from the last plugin's execution, which means that the current plugin and the component which has been wired to it have incompatible class realms.

The specific case for scripting language support means that the component factory doesn't have access to the scripts, taglibs, etc. which are defined in this current plugin, since it cannot use the classloader to discover scripting parts inside the plugin (the plugin and component-factory have sibling, and isolated, class realms).

Until we have a better way of really sharing components inside of plexus, including shared classloading, etc. for loaded components, this will remain a problem.

Came back around to this issue again, to see what the specific problem is. I looked in the code, and it's already doing a lookup on the container per-call to the getWagon() method, so it should be able to use dynamically-added wagons.

What is the specific problem WRT DefaultWagonManager and wagon lookup?

the current problem is this:

we have a core plexus container used by the maven application, which defines things like WagonManager; and for each plugin, we have a child container which loads that plugin's specific dependencies (those not filtered by the exclusion filter in DefaultPluginManager). In the deploy plugin, the plugin contained (this has been worked around for now) declared a dependency on wagon-ssh...which means that the scp wagon should have been visible to WagonManager for this plugin's context. HOWEVER, since WagonManager is defined in the parent container, it cannot see components in the child (plugin) container, and therefore has no idea of the scp wagon's existence in the system.

This situation has other implications as well. For example, if we define a new wagon capable of artifact deployment - say webdav - we have to redeploy the maven-deploy-plugin with this new wagon as a dependency. It would probably be smarter in these cases to have a lookup mechanism which is similar to maven's plugin location process (brett's idea), and which would be reusable across maven-artifact, maven-scm, maven-core (plugins), etc.

As for component-factories, the new reliance on nested DefaultPlexusContainer instances rather than a single DefaultArtifactContainer should fix this. This is a special case, since the ComponentFactoryManager is a core plexus component, and is therefore defined in every container instance.

For now, wagon-ssh is included in maven-core's runtime dependencies, and we'll revisit this post-2.0

moving this to post-2.0, since the remaining problems will require a much more intensive fix that we're not prepared to implement for the 2.0 release cycle

marmalade and beanshell mojo support is now excluded from the core, and included on-demand via plugin dependencies.

As noted before, a similar solution for wagon-based things will require a refactor of the WagonManager implementation to allow PluginManager-style lookups.

bringing back to 2.0-beta-1 as I have a simple idea for a fix, if it works

We have "build extensions" - ie providers for wagon, scm that are not
really plugins but additional providers for a particular plexus role.
Currently, these need to be dropped into M2_HOME/lib along with their
dependencies which is not ideal. (SCM ones can be a dependency on the
SCM/release plugin, but there is no scope to later add a new one). In
the future, repository metadata might help us locate plexus components
with a particular role and role hint, but this will hold us over until then.

While we should still make the "standard" ones available out of the box,
it needs to be easy to add more via the project in a reproducible way,
so I propose:

<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-alpha-4</version>
</extension>
</extensions>
</build>

This is here instead of in dependencies for clarity and so that you can
use them both as an extension and as a dependency without having to
worry about matching versions or scope.
Extensions are:

• inherited from the parent
• have NO configuration
• the version can be omitted (use RELEASE) or use ranges like a plugin
  and will be populated by the release plugin

At execution, it needs to be available to the core code (eg
DefaultWagonManager), and also particular plugins (eg maven-scm-plugin).
For now, I just intend to push the extensions into the core classloader.
I think we might eventually need to construct a per-project execution
realm as a basis for plugin realms and recreate those plugin realms for
each project (currently it is only ever created for one plugin - so
mutliple versions of a plugin might have problems).

the type handlers will need to be loaded into the extension classloader, so I'll do MNG-226 first

implemented <extensions/> with some limitations which have been filed separately for later milestones

needs to be added for pluginManagement