[slf4j-dev] OSGi support in slf4j

[Hugues Malphettes]

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.

>
>>    * 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.
>
>>    * 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.

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.
I'm on IRC freenode #slf4j if this type of communication helps.

Best regards,
Hugues.

>
> ditto
>
> --
> Ceki
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev
>