>> I'm on IRC freenode #slf4j if this type of communication helps. > > Thanks for the offer. I don't think I'll hang around that irc channel (or > any other irc channel), but appreciate the offer nonetheless. Sorry for the confusion. I meant #qos.ch as mentioned on http://logback.qos.ch/mailinglist.html Cheers, Hugues
On Wed, Sep 15, 2010 at 10:07 PM, Ceki Gülcü <[email protected]> wrote: > On 15/09/2010 11:30 PM, Hugues Malphettes wrote: >> >> 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. > > Ok, then. Let's do it. > >>> >>>> * 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. > > Ack (short for acknowledge). > >>>> * 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. > > I guess such functionality targets applications which can never ever be > stopped. Changing logging frameworks is something one does very few times > (if ever) during the lifetime of an application and on those occasions you > stop, update and restart the running instances. > >> 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. > > OK, let's give BND a shot. > >> I'm on IRC freenode #slf4j if this type of communication helps. > > Thanks for the offer. I don't think I'll hang around that irc channel (or > any other irc channel), but appreciate the offer nonetheless. > > -- > 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
