CODEWITHSUNDEEP
javamavenloggingslf4j
user1884155
user1884155

Reputation: 3736

Redundant inclusion of slf4j libraries

I have a java webapp project that uses 3 self-made libraries. Here's the lay-out:

Top level project A
|
+- Self-made library B (no dependencies on C or D)
+- Self-made library C (depends on D)
+- Self-made library D (no dependencies on B or C)
|
+- Other libraries that I didn't make myself

I want to use Slf4j logging in these 4 java projects. In my IDE these are 4 separate java projects. Only A is a dynamic web project. By adding the jar slf4j-api to each java project, I'm able to instantiate the loggers in the relevant classes and my code compiles fine.

Next I add the slf4j-log4j binder jar and the log4j jar (with matching versions) together with a log4j.properties file to all of my projects. Now each project would actually log something using the log4j implementation

I know that each of my 4 projects has the same slf4j and log4j version, and I also know that the top-level project depends on the 3 others and they will all be packaged in one big war file in the end. Because of this it feels redundant to add all the necessary jars to each project indiviudally. However, I can't remove them, because then each project individualy wouldn't compile.

I'm using maven, and I want to know in which pom I should write which dependencies, and in which project I need to add a log4j.properties file so that each project individually gives no (compile) errors in my IDE, but I also minimise the redundant inclusion of the same logging libraries.

I think that only adding the slf4j-api is enough for the libraries B, C and D, and that I only need to provide an implementation (log4j + log4j binder) in the webapp project. However, then I still have the same jar in 4 projects.

Upvotes: 1

Views: 340

Answers (1)

palimpsestor
palimpsestor

Reputation: 1069

You are correct, your only compile-time logging dependency in B, C, and D, should be on slf4j-api. (The idea being that if those libraries were provided to somebody else, they would be free to use log4j, logback, or whatever else.)

You are also right that it's only your webapp project, or more generally whichever project you actually want to perform logging when it runs, that needs the concrete log4j binding. It's also only that project that needs a log4j.properties file (in the classpath, at runtime).

Since the submodules are coding to the SLF4J api, there is no avoiding them having compile-time dependencies on slf4j-api. If you would rather not declare that dependency multiple times, then you can have them all inherit that dependency from a common parent pom.

Upvotes: 1

Related Questions