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