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@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@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