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