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

[John E. Conlon]

Ceki Gülcü wrote:
> John,
>
> Do you have a suggestion how we could avoid duplication of slf4j-api 
> classes in the various bindings? Can this be done using maven-bundle-plugin ?
>   
At the moment I can think four approaches to removing the duplication of 
classes in the bindings that sit on 'Sally's application's classpath.

1. Keep the packages split across the api and binding projects, continue 
to rely on single classloader joining at runtime, and move back to a 
Require-Bundle approach for osgi support. We won't need the 
maven-bundle-plugin in the binding projects for this.

2. Remove the split packages by consolidating the packages into the api 
and binding jars, and use a 'service implementation' discovery similar 
that suggested by Eric in the "aufgeregt" thread :-) :

http://www.qos.ch/pipermail/logback-user/2007-February/000129.html

We should not depend on a sun impl for this so we would have to provide 
our own implementation, Boris has provided an example at:

http://marc.theaimsgroup.com/?l=slf4j-dev&m=117157566417290&w=2

While I have not experimented with his code, I do see one area that 
would require a change for it to work in an OSGi environment.

 public Object obtainFactory(ClassLoader cl) {
        ILoggerFactory ret = null;       
        InputStream is = cl.getResourceAsStream(SERVICE_ID);

Note: couldn't use a context classloader as it would not find the 
classes in an OSGi runtime. Sun's service api offers similar signatures.

3. Keep split packages and retain current way of combining api and 
bindings.  Remove OSGi decorations and maven-bundle-plugin from the five 
bindings projects.   Create five additional OSGi 'pom' projects that 
just wrap the api and bindings to create OSGi binding bundles.  These 
projects would only have a pom.xml (no code) and the artifacts they 
create would be the same bundles as we are now producing in the binding 
projects.  All other projects producing native jar/osgi bundles (like 
the adapters) would remain unchanged.
(In this case Sally would not use the osgi-xxx-binding bundles.)

4. Convince Sally to run OSGi ;-)

 From an OSGi perspective I would rate them in order of functionality 
from higher to lower - 4, 3, 2, 1.

kind regards,
John



> At 07:52 PM 2/19/2007, Ceki Gülcü wrote:
>
>   
>> At 08:25 PM 2/18/2007, John E. Conlon wrote:
>>
>>     
>>>> 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?) ;-)
>>>       
>> Hi John,
>>
>> The driving premise behind SLF4J is to reduce surprises. I think we
>> should do things by the book and avoid duplication. Since SLF4J
>> version 1.1, user's have been asked to have two jars, slfl4-api.jar in
>> addition to a binding. In SLF4J 1.3, the general arrangement remains
>> the same, except that slf4j-api is now self-sufficient as a
>> compile-time dependency.
>>
>> I quite like this user-story. Alice and Bob expose slf4j-api as a
>> transitive dependency, while Sally, the end-user, chooses to depend on
>> a binding of her own selection.  We respond to Eric Crahen's initial
>> request [1] without fundamentally changing how SLF4J works.
>>
>> I do not wish to hide behind backward-compatibility excuses. We
>> finally have a nice and clear separation between slf4j-api and
>> slf4j-binding. Let's keep it clean and simple even if it costs an
>> extra jar on the class path.
>>
>> [1]
>> http://www.qos.ch/pipermail/logback-user/2007-February/000129.html
>>
>>
>>
>>     
>>> a good weekend for you too,
>>> John
>>>       
>> --
>> Ceki Gülcü
>> Logback: The reliable, generic, fast and flexible logging framework for Java.
>> http://logback.qos.ch
>>
>> _______________________________________________
>> dev mailing list
>> dev at slf4j.org
>> http://www.slf4j.org/mailman/listinfo/dev
>>     
>
>