[slf4j-dev] OSGi support in slf4j

[Ceki Gülcü]

Heiko,

It would be reassuring to the OSGi layman like myself, if both you and
Hugues could reach consensus on this topic. It was a rather lengthy
process to reach the current level of stability wrt OSGi manifests in
SLF4J.

On 15/09/2010 9:18 PM, Heiko Seeberger wrote:
> Hi Hugues,
>
> Thanks a lot for your attention!
>
> Not sure, but as far as I understand, you probably got something wrong
> regarding the uses directive: There is no version! The only piece of
> information that is given is that an exported package "uses" some
> other packages, e.g. org.slf4j.scala uses types from scala.*. Only the
> packages, no versions. But that's enough to  enable the OSGi container
> to make a consistent classpath. I know that this is an advanced topic,
> but it is a really important one. There are good examples in the OSGi
> spec.
>
> Regarding Scala's binary compatibility issues the uses directive is
> very important. And it is helpful in a lot of cases. There are almost
> no cases where it causes trouble. Therefore I suggest to use it.
>
> Heiko
>
> On Wednesday, September 15, 2010, Hugues Malphettes
> <hmalphettes at intalio.com>  wrote:
>> Hi Heiko,
>>
>> Thanks for all the good work on scala and looking in depth into slf4j in OSGi.
>>
>>> There is no uses directive for the exported packages. Well, that cannot be
>>> done manually (see Maven Bundle plugin above)
>> I am not convinced that the use directive is necessary for slf4j.
>> I have not seen a situation for slf4j where the use directive will
>> solve an actual problem.
>> I am afraid that the use directive automatically generated by BND will
>> reflect in the bundle the version of the various jars used during the
>> build: not new constraints that we did not identify and expressed in
>> the manifest already.
>>
>> In my experience, I had to relax the use directive in some manifests
>> generated by BND.
>> The use directive would specify that it only works with a different
>> version of a library.
>> In fact it just meant that it was built with a newer version of a
>> library than the one imposed to my environment.
>>
>> The most common case is for packages provided by the JDK such as javax.xml.
>> A BND generated manifest compiled with a specific stax version on the
>> class path will specify in its use directive that it requires
>> javax.xml with a version number.
>> Another library would be compiled with jdk6 instead. BND will then
>> specify that this particular package uses the version "0" of
>> javax.xml.
>> At runtime OSGi will refuse to load in the same class-space those 2
>> libraries because both of them rely on different and incompatible
>> versions of javax.xml
>> Relaxing the manifest of those bundles by removing the use-directive
>> has been the best solution I found so far.
>>
>> Thanks for your attention,
>> Hugues
>>
>> On Wed, Sep 15, 2010 at 12:03 AM, Heiko Seeberger
>> <heiko.seeberger at googlemail.com>  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 bundle symbolic name does not follow "well recognized OSGi conventions":
>>> It should follow the reverse domain naming convention, i.e. org.slf4j.api
>>> 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
>>> I think the import for org.slf4j.impl should be optional, but I have to play
>>> with that one
>>> There is no uses directive for the exported packages. Well, that cannot be
>>> done manually (see Maven Bundle plugin above)
>>>
>>> I suggest I give it a try and change the slf4j-api module to also use the
>>> Maven Bundle plugin. Thoughts?
>>> Heiko
>>>