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

[John E. Conlon]

Ceki Gülcü wrote:
> At 05:37 PM 2/17/2007, John E. Conlon wrote:
>   
>>> 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.
>>     
>
> Trying with the latest commit, I can confirm that the build is
> successful. However, I could not get the build to complete with the
> -Posgi flag. I made a number of modifications which allowed to me get
> further along the way. Please also see my commit message for revision
> 735.
>
>   
>> End users will still only import o.s while adapters clients will import
>> both o.s and o.s.spi.
>>     
>
> [snip]
>
>   
>>> 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.
>>     
>
> Exactly, the idea is to use slf4j-api as a transitive dependency and a
> user-chosen dependency for testing.
>
>   
>>> 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.)
>>     
>
> Assuming Maven 2 is used by all participants, without particular
> action by Sally, slf4j-api would be packaged in the final
> application along with a user-chosen binding, say slf4j-log4j12. In
> that case, we would have the contents of slf4j-api project duplicated,
> once in slf4j-api.jar and once in slf4j-log4j12.jar. It would most
> probably work as expected, but I don't think it's good practice to
> have class files duplicated.
>   
I don't like this class duplication either, but AFAIK given the same 
classloader this should not matter.  The same classloader will load 
which ever it encounters first.  (Maybe I will eat these words latter?) ;-)

a good weekend for you too,
John