As a general answer: let's try with BND and review carefully the generated manifests. On Wed, Sep 15, 2010 at 1:40 PM, Ceki Gülcü <ceki@qos.ch> wrote:
On 15/09/2010 9:03 AM, Heiko Seeberger 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 pom.xml does actually insert a Bundle-Version I downloaded http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.jar and verified that it is there. The pom.xml is customized to insert the Bundle-Version without using BND. Certainly a bit unusual but it does the job.
* The bundle symbolic name does not follow "well recognized OSGi conventions": It should follow the reverse domain naming convention, i.e. org.slf4j.api
Wouldn't this cause other bundles expecting the current symbolic name to fail?
Yes it would make them fail. The best practice for consumer bundles is to use the Import-Package directive so that they don't depend on the naming of the bundle itself. So it all depends how many of the consumers of slf4j-api are following the best practice or using Require-Bundle. If that makes a difference: the re-packaging of slf4j on eclipse-orbit is following the best practice mentioned by Heiko: http://download.eclipse.org/tools/orbit/downloads/drops/S20100831105311/ If it was just me: I would say +1 for following the reverse domain naming.
* 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
SLF4J targets JDK 1.4.
Yes we should update that entry of the manifest.
* I think the import for org.slf4j.impl should be optional, but I have to play with that one
Hugues spent some time to tweak the manifests. I'd seek his input.
We spent quite some time looking into getting rid of the cyclic dependency between slf4j-api and its implementation. http://bugzilla.slf4j.org/show_bug.cgi?id=75 Gunnar went with the fragment approach on eclipse orbit: http://bugzilla.slf4j.org/show_bug.cgi?id=75#c16 It is my favorite approach so far. I had done a funny experiment to wire the implementation to the API dynamically. Frankly I would not use that: it is too much complexity for no good reason. We could also use a Dynamic-Import. If one of us has the need and the time we could develop something OSGi specific to be able to plug and unplug slf4j implementations dynamically. If I remember well the import is not marked as optional because the bundle does not work unless there is in fact a bundle that provides the org.slf4j.impl package. I don't have a strong argument to decide whether it should be optional or not.
* There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above)
Let's look at what is generated by BND. I'm on IRC freenode #slf4j if this type of communication helps. Best regards, Hugues.
ditto
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev