A dep that includes log4j in its jar

many libs misbehave by bundling deps

(usually this only gets noticed when you realize you are using the wrong version of some lib...)

A nightmare in this scenario

also log4j is a likely candidate for that kind of bundling, because the lib authors want to bake in logging features...

Hard to get rid of with out getting rid of the dep, annoying to track down which dep is behaving badly

Basically you have to look at all the jars of your deps and see if they contain log4j classes

this does seem like something a plugin could do, logging out class files in deps / searching for classes matching some pattern and reporting their provenance

Some way to bind class file name prefixes to maven coords

There are some that do this, although I don't recall the names

Probably findable here via search, they've been discussed

tools.logging is a dependency of e.g. Aleph or https://github.com/yogthos/config it seems.

tools.logging does not depend on log4j

tools.logging can use log4j as an underlying framework, if you also provide log4j as a dependency and its either explicitly configured or automatically found via the load order at https://github.com/clojure/tools.logging/#configuration

Anyone here ever played with ferns and frons? http://webyrd.net/frons/frons.pdf