I'm planning to include - but shade, making it inaccessible to plugins and the outside world - log4j 1.2.14. It seems that httpclient actually depends on clogging 1.0.4 (which is also shaded in to avoid classloader conflicts with plugins), but that the logging strategy employed by clogging actually looks for log4j classes by name on the classpath and will try to load them if they exist. If a plugin depends on log4j and happens to be the trigger that causes the http wagon, httpclient, and clogging to load, then clogging gets confused and tries to use the log4j included with the plugin. This is causing quite a bit of trouble in these cases, basically resulting in a stacktrace.
By including log4j in the core classpath, we can work around this strategy and make plugins that depend on log4j safe to use. I'm still working on this issue, and if I can supply a configuration for commons-logging that will allow us to leave out log4j, I'll do that instead.