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 <[email protected]> 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 > <[email protected]> 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 >> [email protected] >> http://qos.ch/mailman/listinfo/slf4j-dev >> > _______________________________________________ > slf4j-dev mailing list > [email protected] > http://qos.ch/mailman/listinfo/slf4j-dev > -- Heiko Seeberger 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 [email protected] http://qos.ch/mailman/listinfo/slf4j-dev
