Max Spring discovered a stack overflow in http://jenkins.361315.n4.nabble.com/channel-example-and-plugin-classes-gives-ClassNotFoundException-td3756092.html that pointed this call into thread context classloader (TCL) as the culprit. Independently, Paul Sandoz discovered the same issue in our products. If TCL is another classloader that delegates to UberClassLoader (UCL), this code causes infinite recursion.

And moreover, given the goal of UCL, it seems wrong that this class is changing behaviour based on contextual information like TCL.

 In looking at 4de81f1e, the change was introduced to make sure XStream unmarshalling invoked from Plugin.start() would see the classes in that plugin. This was an issue back then when plugins are prepared and loaded one by one, as UCL didn't have visibility into plugins being prepared. But in the current Jenkins, classloaders for all the plugins are prepared, before any plugin gets started, so by the time Plugin.start() runs, UCL is fully functioning.

 Therefore, there's no need to consult TCL for the purpose of resolving its own classes. I could have also removed the code that sets TCL, but because some libraries often depend on TCL and doesn't properly look at caller class, I'm leaving it in, even though it's generally a bad practice to rely on TCL in multi-classloader apps like Jenkins

as they don't change a lot build will be faster !

upgrade to maven 3.0.3 (will prevent issue when pom parsing phase : http://jira.codehaus.org/browse/MNG-4963)

Revert "adding something to DescriptorExtensionList should cause addition to ExtensionList of Descriptors as well."

This reverts commit 04d64fd4.

By the time MavenModuleSetBuild.notifyModuleBuild() is called, we need the processing on one module to be completed.

adding something to DescriptorExtensionList should cause addition to ExtensionList of Descriptors as well.

To make views reusable elsewhere, removing "Manage Jenkins" from View and moving the logic to the top-level Hudson class.