<br><br><div class="gmail_quote">On Tue, Nov 2, 2010 at 2:43 PM, Heiko Seeberger <span dir="ltr"><<a href="mailto:heiko.seeberger@googlemail.com">heiko.seeberger@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thank you for reviewing!<br>
<br>
If I understand correctly we should relax the versioning policy to<br>
import ranges from x.y instead of x.y.z, right? IMHO that makes sense.<br>
An it's easily done: Just a little switch in the config. Let me know<br>
and I will change it.<br></blockquote><div><br></div><div>That would be the one thing I would change.</div><div>Thanks Heiko!</div><div>Hugues</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Heiko<br>
</font><div><div></div><div class="h5"><br>
On Tuesday, November 2, 2010, Hugues Malphettes <<a href="mailto:hmalphettes@intalio.com">hmalphettes@intalio.com</a>> wrote:<br>
> Hi Ceki,Thanks for reminding us to review the changes introduced by BND.<br>
> On Mon, Nov 1, 2010 at 2:16 PM, Ceki Gülcü <<a href="mailto:ceki@qos.ch">ceki@qos.ch</a>> wrote:<br>
> Hello all,<br>
><br>
> I pulled in changes made by Heiko <a href="http://github.com/ceki/slf4j/pull/2" target="_blank">http://github.com/ceki/slf4j/pull/2</a>. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar.<br>
><br>
> Manifest-Version: 1.0<br>
> Archiver-Version: Plexus Archiver<br>
> Created-By: Apache Maven<br>
> Built-By: ceki<br>
> Build-Jdk: 1.6.0_16<br>
> Bundle-Description: The slf4j API<br>
><br>
> Bundle-Version: 1.6.1<br>
> Implementation-Version: 1.6.1<br>
> Implementation-Title: slf4j-api<br>
> Bundle-ManifestVersion: 2<br>
> Bundle-SymbolicName: slf4j.api<br>
> Bundle-Name: slf4j-api<br>
> Bundle-Vendor: <a href="http://SLF4J.ORG" target="_blank">SLF4J.ORG</a><br>
> Bundle-RequiredExecutionEnvironment: J2SE-1.3<br>
> Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1,<br>
> org.slf4j.helpers;version=1.6.1<br>
> Import-Package: org.slf4j.impl;version=1.6.0<br>
><br>
> Here is the version generated after Heiko's changes have been applied:<br>
><br>
> Manifest-Version: 1.0<br>
> Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO<br>
> T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S<br>
> NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1<br>
> .6.2.SNAPSHOT"<br>
> Ignore-Package: org.slf4j.impl<br>
> Implementation-Title: slf4j-api<br>
><br>
> Built-By: ceki<br>
> Tool: Bnd-0.0.357<br>
><br>
> Bundle-Name: SLF4J API Module<br>
><br>
> Created-By: Apache Maven Bundle Plugin<br>
><br>
> Bundle-RequiredExecutionEnvironment: J2SE-1.4<br>
><br>
> Bundle-Vendor: QOS.ch<br>
> Build-Jdk: 1.6.0_16<br>
> Bundle-Version: 1.6.2.SNAPSHOT<br>
><br>
> Bnd-LastModified: 1288644768461<br>
> Bundle-ManifestVersion: 2<br>
> Bundle-License: <a href="http://www.opensource.org/licenses/mit-license.php" target="_blank">http://www.opensource.org/licenses/mit-license.php</a><br>
> Bundle-Description: The slf4j API<br>
> Bundle-DocURL: <a href="http://www.qos.ch" target="_blank">http://www.qos.ch</a><br>
><br>
> Bundle-SymbolicName: org.slf4j.api<br>
> Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel<br>
> pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA<br>
> PSHOT,1.7)"<br>
><br>
><br>
> Admittedly, I am a little lost. The previous MANIFEST file imported org.slf4j.impl, whereas the latest MANIFEST does not. Strangely enough, org.slf4j.impl is not mentioned at all.<br>
> Heiko packages org.slf4j.impl as bundle fragments that are hosted by org.slf4j.api.<br>
><br>
> In our situation, there must not be more than one provider of org.slf4j.impl: this means there must one and exactly one fragment that provides org.slf4j.impl.<br>
><br>
> At runtime the fragment classes are part of the classloader of org.slf4j.api.This is why org.slf4j.api does not import org.slf4j.impl at all.<br>
> The MANIFEST.MF of org.slf4j.api does look good.<br>
><br>
> It contains a few of extra lines that are read by BND alone: Private-Package and Bnd-LastModified for example.<br>
><br>
><br>
> The MANIFEST.MF of jcl.over.slf4j (aka jcl-over-slf4j) uses these statements: Export-Package: org.apache.commons.logging;version=1.1.1, org.apache. commons.logging.impl;version=1.1.1<br>
><br>
> Import-Package: org.slf4j;version=1.6.2.SNAPSHOT, org.slf4j.spi;versio n=1.6.2.SNAPSHOT<br>
> It will work.The versioning constrain on the import-package is I think too much: strictly speaking, the produced fragment is going to work with version 1.6 of slf4j.<br>
><br>
> I apologize for sounding picky and in the case where we always build and distribute together slf4j-api and jcl-over-slf4j it probably does not matter much.If we were to adopt BND to generate the MANIFESTs of logback let's make sure that we generate version=1.6 only so that we don't suddenly force everyone to upgrade both slf4j and logback at once for no actual reason.<br>
><br>
><br>
> Best regards,Hugues<br>
><br>
><br>
><br>
><br>
> In earlier message Heiko wrote:<br>
><br>
>> As all the logging backends are fragments I excluded org.slf4j.impl<br>
>> package from imported packages. This means you can install the<br>
>> slf4j-api bundle in an OSGi container successfully without a backend. > Not sure whether this is what we want.<br>
><br>
><br>
> I think it makes life easier if the slf4j-api bundle can be installed without a back-end. However, this is assuming that a desired back-end bundle can be installed and successfully bound with slf4j-api. (It is an obvious requirement but still may be useful to mention.)<br>
><br>
> This version can be pulled in either from <a href="http://github.com/weiglewilczek/slf4j" target="_blank">http://github.com/weiglewilczek/slf4j</a> (master) or from <a href="http://github.com/ceki/slf4j" target="_blank">http://github.com/ceki/slf4j</a> (weiglewilczek-master).<br>
><br>
> Your comments are most welcome,<br>
><br>
> --<br>
><br>
> Ceki<br>
> _______________________________________________<br>
> slf4j-dev mailing list<br>
> <a href="mailto:slf4j-dev@qos.ch">slf4j-dev@qos.ch</a><br>
> <a href="http://qos.ch/mailman/listinfo/slf4j-dev" target="_blank">http://qos.ch/mailman/listinfo/slf4j-dev</a><br>
><br>
><br>
><br>
<br>
</div></div><div class="im">--<br>
Heiko Seeberger<br>
<br>
Company: <a href="http://weiglewilczek.com" target="_blank">weiglewilczek.com</a><br>
Blog: <a href="http://heikoseeberger.name" target="_blank">heikoseeberger.name</a><br>
Follow me: <a href="http://twitter.com/hseeberger" target="_blank">twitter.com/hseeberger</a><br>
OSGi on Scala: <a href="http://scalamodules.org" target="_blank">scalamodules.org</a><br>
Lift, the simply functional web framework: <a href="http://liftweb.net" target="_blank">liftweb.net</a><br>
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through<br>
Actors: <a href="http://akkasource.org" target="_blank">akkasource.org</a><br>
</div><div><div></div><div class="h5">_______________________________________________<br>
slf4j-dev mailing list<br>
<a href="mailto:slf4j-dev@qos.ch">slf4j-dev@qos.ch</a><br>
<a href="http://qos.ch/mailman/listinfo/slf4j-dev" target="_blank">http://qos.ch/mailman/listinfo/slf4j-dev</a><br>
</div></div></blockquote></div><br>