When adding plugins with classpath://* not the complete classpath is being considered.

Excerpt from mail

> Now, we're actually probably going to be generating a list of explicit URIs
> to jar files in a defined location (similar to how Jenkins loads plugins
> from $HUDSON_HOME/plugins), so this won't really affect how we do the plugin
> loading, but I'd like to understand what's going on with JSPF's handling of
> the classpath to keep from getting bitten by it in the future (e.g. if we

Could it be that the web server / application runtime adds the code where the 
PluginManager is being created (i.e., PluginService) dynamically. In that case, 
JSPF wouldn't 'see' anything about where it is right now, and also wouldn't be 
able to find the other plugins. 

--> Should also check the classloader source of PluginManager.

Original issue reported on code.google.com by r.biedert on 20 May 2011 at 7:55

gearlles / jspf

When adding plugins with classpath://* not the complete classpath is being considered. #29