[slf4j-dev] jcl-over-slf4j module not building

[John E. Conlon]

Ceki Gülcü wrote:
> At 11:05 PM 2/16/2007, John E. Conlon wrote:
>   
>> Your right, neither do I want to increase the number of classes in the
>> org.slf4j packages.  But we are basically doing the same kind of thing
>> with the second approach as well - exposing our selves to greater
>> coupling by clients.  By exporting the org.slf4j.spi package we are
>> exporting what was once a private package and all classes in it, on to
>> the OSGi package matrix.
>>     
>
> The o.s.spi package contains two interfaces, namely
> LoggerFactoryBinder and MarkerFactoryBinder. I am not worried about
> exposing these interfaces into the public.
>
>   
That makes sense.  I just committed  the change.  Project now builds 
with -Posgi flag.

End users will still only import o.s while adapters clients will import 
both o.s and o.s.spi.
>> Right now we are in a very good position regarding client coupling to us
>> and dependencies we have on other third party jars.  Although we are
>> still using split packages to deliver our Logger service but now for
>> 1.5.0 we do the 'package join' at maven build time versus before we had
>> our clients do it on the classpath.
>>     
>
> It's quite nice that we have the technical ability to package all
> SLF4J classes within each binding. However, I am not 100% convinced
> that doing so yields the best user experience, especially as seen by
> developers of libraries.
>
> Assume Alice is the developer of some library, say La. As far as
> Alice is concerned, imposing slf4j-api as a dependency of La is
> acceptable while imposing a binding is not. In SLF4J 1.2, Alice has to
> depend on a binding in La, typically slf4j-simple, and then let the
> user change the binding. It would be more convenient if La depended on
> slf4j-api only. This would allow the end-user to import La as is,
> including its dependency on slf4j-api without change.
>   
Perhaps I am not seeing it but, wouldn't it work like it always has? 
Alice for her library still imposes the slf4j-api as a dependency and 
for testing uses one of the bindings. 
> For instance, if Bob was the author of some library, say Lb (how
> original) which depended on La and by transitivity on slf4j-api, Bob
> could use the SLF4J API without additional work.
>   
Bob uses La for Lb which carries with it only the slf4j-api dependency, 
Bob then uses whatever binding he wishes for testing his Lb.

Sally now builds an application from Lb and uses whatever binding she 
wants but when packaging the application for end user distribution only 
needs to add a slf4j binding to the installation zip.  (Even if she 
added the slf4j-api and the binding it should still work as expected.)

John