Also this should probably be factored out:

WARNING [org.netbeans.ProxyClassLoader]: Will not load class org.apache.commons.httpclient.params.DefaultHttpParams
arbitrarily from one of ModuleCL@1e7c5cb[org.netbeans.modules.maven.embedder] and
ModuleCL@4be2cc[org.netbeans.libs.bugtracking] starting from SystemClassLoader[358 modules]; see
http://wiki.netbeans.org/DevFaqModuleCCE

unfortunately for me it means extracting the apache-commons and apache-httpclient content from the maven embedder jar.
If the match of versions for both dependencies are not exact I ran into higher risk of bugs. The same applies when
people upgrade the version of the dependencies modules. Who is loading the http-client classes from the system
classloader anyway?

"Who is loading the http-client classes from the system classloader anyway?" - don't know offhand. PCL could be changed
to log a stack trace but I fear this would be too noisy. Could be changed to log a stack trace at FINE, say, as well as
the one-line WARNING; then you could run with PCL.level=FINE and see it.

"Who is loading the http-client classes from the system classloader anyway?" 
mylyn (used by bugtracking) depends on the http-client library - i will inspect ...

For example:

java.lang.ClassNotFoundException: Will not load class org.apache.commons.logging.impl.SimpleLog arbitrarily from one of
ModuleCL@13785d3[org.netbeans.modules.maven.embedder] and ModuleCL@1dc0e7a[org.netbeans.libs.commons_logging] starting
from SystemClassLoader[428 modules]; see http://wiki.netbeans.org/DevFaqModuleCCE
[catch] at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:241)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:242)
        at org.apache.commons.logging.impl.LogFactoryImpl.createLogFromClass(LogFactoryImpl.java:1005)
        at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:782)
        at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
        at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:307)
        at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:645)
        at org.apache.commons.httpclient.params.DefaultHttpParams.<clinit>(DefaultHttpParams.java:54)
        at org.eclipse.mylyn.commons.net.WebUtil.<clinit>(WebUtil.java:123)
        at org.netbeans.libs.bugtracking.BugtrackingRuntime.init(BugtrackingRuntime.java:76)
        at org.netbeans.modules.bugtracking.BugtrackingManager.init(BugtrackingManager.java:125)
        at org.netbeans.modules.bugtracking.BugtrackingManager.getInstance(BugtrackingManager.java:85)
        at org.netbeans.modules.bugtracking.util.BugtrackingUtil.getKnownRepositories(BugtrackingUtil.java:148)
        at org.netbeans.modules.bugtracking.vcshooks.HgHookImpl.createComponent(HgHookImpl.java:215)
        at org.netbeans.modules.mercurial.ui.commit.CommitPanel.initHooks(CommitPanel.java:147)
        at org.netbeans.modules.mercurial.ui.commit.CommitAction.commit(CommitAction.java:143)
        at org.netbeans.modules.mercurial.ui.commit.CommitAction.performAction(CommitAction.java:132)
        at org.netbeans.modules.mercurial.ui.actions.ContextAction.actionPerformed(ContextAction.java:69)

I'm guessing LogFactoryImpl.discoverLogImplementation is using Thread.CCL to find itself. (A common stupid design shared
with Xerces - if it is looking up its _own_ impl it should not use the CCL!) Perhaps BugtrackingRuntime.init should
temporarily (finally-block) set Thread.CCL to the WebUtil.class.getClassLoader().

I am concerned however about:

java.lang.ClassNotFoundException: Will not load class org.apache.commons.logging.impl.LogFactoryImpl arbitrarily from
one of ModuleCL@13785d3[org.netbeans.modules.maven.embedder] and ModuleCL@1dc0e7a[org.netbeans.libs.commons_logging]
starting from SystemClassLoader[428 modules]; see http://wiki.netbeans.org/DevFaqModuleCCE
[catch] at org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java:241)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at org.netbeans.lib.uihandler.LogFormatter.printFrame(LogFormatter.java:140)
        at org.netbeans.lib.uihandler.LogFormatter.printThrown(LogFormatter.java:215)
        at org.netbeans.lib.uihandler.LogFormatter.format(LogFormatter.java:329)
        at org.netbeans.lib.uihandler.LogRecords.write(LogRecords.java:84)
        at org.netbeans.modules.uihandler.Installer.writeOut(Installer.java:418)
        at org.netbeans.modules.uihandler.UIHandler$1WriteOut.run(UIHandler.java:105)

which makes it look like commons_logging is actually interfering somehow with java.util.logging.

Integrated into 'main-golden', will be available in build *200903191401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c88f42ee0005
User: Jesse Glick <jglick@netbeans.org>
Log: Diagnostics for #160378.

Seems to be already fixed,according to automated message.

the commons.logging classes are still in the embedder, so the issue is still there.

http://hg.netbeans.org/main/rev/170df48c8ef3

Integrated into 'main-golden', will be available in build *200906040201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/170df48c8ef3
User: Milos Kleint <mkleint@netbeans.org>
Log: #160378 cut the commons-logging bits out of the maven-embedder binary

*** Issue 167993 has been marked as a duplicate of this issue. ***

*** Issue 168538 has been marked as a duplicate of this issue. ***

*** Issue 169413 has been marked as a duplicate of this issue. ***