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

[Steven Parkes]

I buy most of this.

I don't agree entirely with the idea that using a provided-scope dependence at the webapp level is not a hack. The primary use case for provided (per the docs) is for things like the servlet api where you absolutely expect the container to provide the dependence. Using provided at a higher level to override a compile dependence at a lower level is a bit strange: I'm putting in a dependence I don't need solely to alter a library dependence. That just doesn't make sense … and among other things, if the library ever drops its dependence, I'll still be dependent on it even though I have no use for it whatsoever. And while this pattern seems pretty widespread, I couldn't find an explicit example of it in the maven docs on dependences: they use overrides to override versions but not to change scope. The behavior can be deduced from the docs, I think, but it's not called out explicitly.

Instead, it seems like this is what maven exclusions were developed for: 

"Since maven 2.x resolves dependencies transitively, it is possible for unwanted dependencies to be included in your project's classpath. Projects that you depend on may not have declared their set of dependencies correctly, for example. "

So I buy that an arbitrary library wouldn't want a provided dep (and this was the case that prompted this: a library predominantly but not always used within a j2se container) and it needs to be removed via an exclusion or an override.

 I find the case of j2se-specific libraries a bit ambiguous. While it's not like j2se, where servlet must be provided by the container, there are always going to be multiple classloaders. Should an arbitrary j2se-specific library presume it knows what classloader slf4j is going to get loaded into? I don't see any good answer to that. Assuming the case where the webapp doesn't mention it, a war that doesn't include slf4j-api isn't going to work in a container that doesn't provide it and a war that does include it isn't going to work (or at least isn't guaranteed to work) in a container that does include it.

So unless you completely isolate the webapp logging from the container logging, you can't do something that's completely generic. So I understand (I think) the issues and know how to manage them.

It turns out it's not the sbt webapp plugin that has an issue but sbt itself (I think). I don't think sbt follows the maven way of overriding deps. Spec'ing a provided-scope dependence at a higher-level doesn't override the default/compile scope of a dependence. sbt has an "intransitive/nontransitive" decoration for dependencies which works but isn't as clean since it means I have to manually depend on the balance of the dependences.

Thanks for the help.