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

[Robert Elliot]

My view is that it is best practice to declare slf4j-api as a compile dependency.  As the writer of a library you do not know how a user will use it - they may use it in a standalone app with no container at all.  To declare it as provided would be deeply confusing to someone expecting transitive dependency management to ensure that all their dependencies were present.

If a particular user decides to deploy a war in a context where they will choose to provide slf4j-api via a container, that is their call - and far from a hack or workaround, it is in my view entirely appropriate for them to then declare it as a provided dependency; surely that is exactly what the "provided" scope was intended for in Maven?

On 30 Aug 2011, at 17:27, Steven Parkes wrote:

> 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 ...
> _______________________________________________
> slf4j-user mailing list
> slf4j-user at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-user