[slf4j-user] maven dependence scope best practice for slf4j-api

[Steven Parkes]

This seems to come up all the time for me now:

Is there a stated "best practice" for a maven dependency on slf4j-api for modules/non-terminal-jar projects?

The big question is, it seems, what scope the dependence should be at. The choices generally are compile/default and provided. The difference is whether maven (or something like sbt) when creating a jar/war will include the slf4j-api jar.

The trouble I have is that module writers use the default slf4j-api dependence which then gets the jar stuck in the webapp war. But I want to configure slf4j-api for the whole container and having slf4j-api loaded at in both the container classloader and the webapp classloader pretty much precludes this. It's possible, I think, to make it work by loading both the api and an implementation at both levels, but I really don't want to do that. Unless it's considered the best practice, that ends up being more painful to configure ...

It seems akin to the FAQ "Should my library attempt to configure logging?". I have this desire for a "Should my library have a compile/default dependence on slf4j-api?"  It seems like the same issue: by having a compile/default dependence on slf4j-api, you're constraining how logging will be configured. If you're not a webapp/container/terminal jar, you should assume that the constructor of the final artifact is going to decide how to configure logging and get the api on the classpath.

There appears to be a workaround for this, which is to add an explicit dependence on slf4j-api with a provided scope at the webapp level which overrides an inherited dependence. But this feels like a hack (since I don't otherwise depend on slf4j-api) and presently doesn't work with the sbt webapp plugin.

So I was wondering if either I'm wrong or if there's a summary of this that modules writers could refer to ...