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
Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev