On Mon, Nov 1, 2010 at 2:16 PM, Ceki Gülcü
<ceki@qos.ch> wrote:
Hello all,
I pulled in changes made by Heiko http://github.com/ceki/slf4j/pull/2. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar.
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: ceki
Build-Jdk: 1.6.0_16
Bundle-Description: The slf4j API
Bundle-Version: 1.6.1
Implementation-Version: 1.6.1
Implementation-Title: slf4j-api
Bundle-ManifestVersion: 2
Bundle-SymbolicName: slf4j.api
Bundle-Name: slf4j-api
Bundle-Vendor: SLF4J.ORG
Bundle-RequiredExecutionEnvironment: J2SE-1.3
Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1,
org.slf4j.helpers;version=1.6.1
Import-Package: org.slf4j.impl;version=1.6.0
Here is the version generated after Heiko's changes have been applied:
Manifest-Version: 1.0
Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO
T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S
NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1
.6.2.SNAPSHOT"
Ignore-Package: org.slf4j.impl
Implementation-Title: slf4j-api
Built-By: ceki
Tool: Bnd-0.0.357
Bundle-Name: SLF4J API Module
Created-By: Apache Maven Bundle Plugin
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Bundle-Vendor: QOS.ch
Build-Jdk: 1.6.0_16
Bundle-Version: 1.6.2.SNAPSHOT
Bnd-LastModified: 1288644768461
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.slf4j.api
Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel
pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA
PSHOT,1.7)"
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.
Heiko packages org.slf4j.impl as bundle fragments that are hosted by org.slf4j.api.
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.
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.
The MANIFEST.MF of org.slf4j.api does look good.
It contains a few of extra lines that are read by BND alone: Private-Package and Bnd-LastModified for example.
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
Import-Package: org.slf4j;version=1.6.2.SNAPSHOT, org.slf4j.spi;versio
n=1.6.2.SNAPSHOT
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.
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.
Best regards,
Hugues
In earlier message Heiko wrote:
> As all the logging backends are fragments I excluded org.slf4j.impl
> package from imported packages. This means you can install the
> slf4j-api bundle in an OSGi container successfully without a backend. > Not sure whether this is what we want.
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.)
This version can be pulled in either from http://github.com/weiglewilczek/slf4j (master) or from http://github.com/ceki/slf4j (weiglewilczek-master).
Your comments are most welcome,
--
Ceki