[slf4j-dev] OSGi support in slf4j

[Ceki Gülcü]

On 15/09/2010 11:30 PM, Hugues Malphettes wrote:
> As a general answer: let's try with BND and review carefully the
> generated manifests.
>
> On Wed, Sep 15, 2010 at 1:40 PM, Ceki Gülcü<ceki at qos.ch>  wrote:
>> On 15/09/2010 9:03 AM, Heiko Seeberger wrote:
>>>
>>> Hi,
>>>
>>> My recent changes to the POM of the slf4j-scala-api module show how we
>>> should IMHO be doing OSGi in every module: Don't write the whole
>>> manifest manually, but let the Maven Bundle plugin generate it.
>>>
>>> Looking at the manifest of slf4j-api there are several issues:
>>>
>>>     * There is no Bundle-Version
> The pom.xml does actually insert a Bundle-Version
> I downloaded http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.jar
> and verified that it is there.
> The pom.xml is customized to insert the Bundle-Version without using
> BND. Certainly a bit unusual but it does the job.
>
>>>     * The bundle symbolic name does not follow "well recognized OSGi
>>>       conventions": It should follow the reverse domain naming
>>>       convention, i.e. org.slf4j.api
>>
>> Wouldn't this cause other bundles expecting the current symbolic name to
>> fail?
>
> Yes it would make them fail.
> The best practice for consumer bundles is to use the Import-Package
> directive so that they don't depend on the naming of the bundle
> itself.
> So it all depends how many of the consumers of slf4j-api are following
> the best practice or using Require-Bundle.
>
> If that makes a difference: the re-packaging of slf4j on eclipse-orbit
> is following the best practice mentioned by Heiko:
> http://download.eclipse.org/tools/orbit/downloads/drops/S20100831105311/
>
> If it was just me: I would say +1 for following the reverse domain naming.

Ok, then. Let's do it.

>>
>>>     * I guess that SLF4J is compiled to target 1.5. At least for the JUL
>>>       module it has to be 1.4 at minimum. Therefore I doubt that the 1.3
>>>       execution environment ist the correct setting
>>
>> SLF4J targets JDK 1.4.
> Yes we should update that entry of the manifest.

Ack (short for acknowledge).

>>>     * I think the import for org.slf4j.impl should be optional, but I
>>>       have to play with that one
>>
>> Hugues spent some time to tweak the manifests. I'd seek his input.
> We spent quite some time looking into getting rid of the cyclic
> dependency between slf4j-api and its implementation.
> http://bugzilla.slf4j.org/show_bug.cgi?id=75
>
> Gunnar went with the fragment approach on eclipse orbit:
> http://bugzilla.slf4j.org/show_bug.cgi?id=75#c16 It is my favorite
> approach so far.
> I had done a funny experiment to wire the implementation to the API
> dynamically. Frankly I would not use that: it is too much complexity
> for no good reason. We could also use a Dynamic-Import.
> If one of us has the need and the time we could develop something OSGi
> specific to be able to plug and unplug slf4j implementations
> dynamically.

I guess such functionality targets applications which can never ever be 
stopped. Changing logging frameworks is something one does very few 
times (if ever) during the lifetime of an application and on those 
occasions you stop, update and restart the running instances.

> If I remember well the import is not marked as optional because the
> bundle does not work unless there is in fact a bundle that provides
> the org.slf4j.impl package. I don't have a strong argument to decide
> whether it should be optional or not.
>
>>
>>>     * There is no uses directive for the exported packages. Well, that
>>>       cannot be done manually (see Maven Bundle plugin above)
>
> Let's look at what is generated by BND.

OK, let's give BND a shot.

> I'm on IRC freenode #slf4j if this type of communication helps.

Thanks for the offer. I don't think I'll hang around that irc channel 
(or any other irc channel), but appreciate the offer nonetheless.

--
Ceki