I have project com.samedhi/base that has a logback.xml file and project com.samedhi/derive that also has a logback.xml file. Project 'derive' has a dependency on 'base'. When I "lein trampoline repl" on 'derive', I get the following warning.
....
15:34:30,066 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
15:34:30,066 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
15:34:30,066 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/stephen/Work/com.samedhi/derive/client/config/logback.xml]
15:34:30,067 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
15:34:30,067 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [jar:file:/home/stephen/.m2/repository/com/samedhi/base.app/0.0.1-SNAPSHOT/base.app-0.0.1-SNAPSHOT.jar!/logback.xml]
15:34:30,067 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/home/stephen/Work/com.samedhi/derive/client/config/logback.xml]
15:34:30,129 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
....
So, the problem appears to be that I have two logback.xml's in my classpath. What am I supposed to do to "surpress" the logback.xml from project 'base' when I lein repl from the 'derive' project?
As far as I'm concerned, you should never package a logging config file (logback.xml, log4j.properties, or what have you) inside a JAR file. The whole point of even having a logging config file is to make it easy for the end-user to adjust logging levels by editing the file. Burying it in an archive defeats the purpose of that, because to change the logging level your user has to expand the archive, edit the file, and then re-package the archive.
Here's my preferred layout for a deployed application. It's a little bit more work to set up, but IMO is worth the trouble because it gives you the flexibility and ease of configuration that an uberjar doesn't.
my-app/
bin/
run-app.sh
config/
logback.xml
lib/
my-lib.jar
my-app.jar
Your run-app.sh script would look something like:
BIN=`dirname "$0"`
BASE=$BIN/..
java -cp "$BASE/config:$BASE/lib/*" my-app.main
This has the advantage that, by putting the config directory at the front of the classpath, any logging config file found there should take precedence over anything that might be found in one of the JARs (e.g. included by a third-party library that you have no control over).