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

[Ceki Gülcü]

On 30/08/2011 11:55 PM, Robert Elliot wrote:

Well said.

I also think that the "provided" scope is the way to go here except
for the sbt webapp plugin that Steven mentioned. It's the first time
I hear about the sbt webapp plugin. Anyway, it sounds like said plugin 
does not honor the "provided" scope which in my mind is a bug of the 
plugin rather than the provided scope being a hack.

-- 
QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, 
is looking to hire talented software developers. For further details, 
see http://logback.qos.ch/job.html


 >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 ...