[slf4j-dev] Separating API and binding

[Graham Lea]

Are you planning on the "binding" still occurring in StaticLogBinder?
If so, in which jar would this class be?
I'll assume "the logging-specific JAR", and ask the next question, which 
is, Is it a good idea for the API jar to refer to a class that is not in 
the API?
Is the separation really cleaner if the API jar requires classes that 
aren't contained in itself?

Some things to think about there.
Come back at me if what I've said doesn't make sense.

Graham.

Ceki Gülcü wrote:

>
>
> Hello all,
>
> It has been observes that while SLF4J offers abstraction of for 
> various logging systems through compile-time bindings, it bundles the 
> SLF4J API and a particular binding in a single jar file. Thus, we 
> currently have
>
> slf4j-nop.jar
> slf4j-simple.jar
> slf4j-jdk14.jar
> slf4j-jul.jar
>
> each of which contains a copy of SLF4J API and a corresponding binding.
>
> I think it would be somewhat cleaner to separate the API in its own 
> jar file. Thus, we would have
>
> slf4j-api.jar (just the API with no particular binding)
>
> slf4j-nop.jar    (only the nop binding, no API)
> slf4j-simple.jar (only the simple binding, no API)
> slf4j-jdk14.jar (only the jdk14 binding, no API)
> slf4j-jul.jar (only the jul binding, no API)
>
> The only down side to this approach is that the user would need to 
> deploy two jar files instead of one. The upside is a clearer 
> separation between API and implementation.
>
> Is there any opposition to this approach?
>
> Your comments are most welcome.
>
>