SLF4J-Test packaging vs testing classpath


(mike mills) #1

I use the Slf4j-Test library to unit test that log messages are generated for certain events.

At runtime I wish to use log4j instead of slf4j-test. This usually means that you include the log4j dependencies in the runtime configuration, and the slf4j-test libraries in the testCompile configuration.

Unfortunately, due to the way slf4j chooses the implementation at runtime, it can lead to tests failing because slf4j uses the log4j implementation during tests (ie log messages end up in the log file rather than in the TestLogger framework)

As this build is using the Application plugin I am looking for a solution that is compatible with that plugin.

I have created an extra configuration for the log4j jars but I can not work out how to get it included on the classpath of the final zip distribution (getting the lib into the zip is easy, but the lib is not written to the classpath hardcoded into the start script created by the application plugin).

My preferred solution would be to modify the test classpath to remove the specific log4j runtime jars. A less desirable variation would be to remove all runtime jars from the test classpath. This would be the cleanest and safest solution IMHO as if anything goes wrong the worst case is that tests fail as opposed to the classpath post deployment being affected.

Does anyone have a solution that removes certain jars from the test classpath but still allows them to end up in the final zip distribution?


(mike mills) #2

Ok, so now I have written the problem down and stepped away from the issue the answer came to me…

test {
    classpath = classpath.filter {!it.name.contains('log4j-slf4j-impl')}
}

This is a generic way to remove any unwanted library from the test classpath.