Ceki Gülcü wrote: > Hello all, > > Using the latest SLF4J code from the repo (rev. 752), I am able to > start both the slf4j-api and slf4j-simple bundles. Just as > importantly, the slf4j-api bundle successfully exports the "org.slf4j" > package. > > The MANIFEST.MF file for slf4j-api reads: > > Implementation-Title: slf4j-api > Bundle-ManifestVersion: 2 > Bundle-SymbolicName: slf4j.api > Bundle-Name: slf4j-api > Bundle-Vendor: SLF4J.ORG > Export-Package: org.slf4j;version=1.3, org.slf4j.spi;version=1.3, > org.slf4j.helpers;version=1.3 > Import-Package: org.slf4j.impl > > The MANIFEST.MF file for slf4j-simple reads: > > Implementation-Title: slf4j-simple > Bundle-ManifestVersion: 2 > Bundle-SymbolicName: slf4j.simple > Bundle-Name: slf4j-simple > Bundle-Vendor: SLF4J.ORG > Require-Bundle: slf4j.api > Export-Package: org.slf4j.impl > Import-Package: org.slf4j, org.slf4j.spi, org.slf4j.helpers > > > There is none of the "partial=true;mandatory:=partial" crap we had > previously. > > "Crap" is necessary to prevent client bundles that import the org.slf4j package from being 'wired' by the OSGi runtime classloader matrix to the slf4j-api bundle. Clients wired to this bundle will get ClassNotFoundExceptions when they try to use get a logger. This is because its packages org.sl4fj and org.slf4j.impl are 'split' across the api and the binding bundle. It will look okay as long as no bundle tries to load any classes.
As soon as I can build the trunk I will adjust latest metadata to accommodate the split packages and preform the OSGi profile tests. kind regards, John _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
