You can clone with
HTTPS or Subversion.
When running lein-repl, reply is added to the project's classpath. reply depends on commons-logging through cd-client, clj-http and the apache http client. This causes problems in projects that use clojure.tools.logging with a logger other commons-logging, since commons-logging has the highest priority when clojure.tools.logging looks for java logging implementations. When the project is using slf4j for example, the project's logging configuration ends up being ignored.
In application code, the commons-logging dependency is less of an issue, since when using slf4j for example, a dependency on org.slf4j/jcl-over-slf4j can be added to the project.
Can clojure.tools.logging be explicitly configured to prefer a given backend as a workaround while we try to come up with a better solution?
might do the trick (untested), and would allow configuration of all calls going through clojure.tools.logging, but still gives no control over logging via the commons-logging interface in say clj-http. For that I think the org.slf4j/jcl-over-slf4j dependency would need to be added.
There are no doubt similar work arounds for log4j.
For tools.logging 0.2.1 and before, the above should be:
(binding [*ns* (the-ns 'clojure.tools.logging.slf4j)]
The logger specific namespaces were removed in tools.logging 0.2.2, so this would need adjusting for that version and later.
Looks like the reorg-repl branch fixed this.