Ceki Gülcü wrote: > Hello John and others, > > LoggerFactory class currently delegates manufacturing work to the factory > returned by > StaticLoggerBinder. While all existing bindings distribute their own copies > of LoggerFactory, this copy is identical, except paradoxically in logback > version 0.9 released just a few days ago. > > I propose that we include LoggerFactory in slf4j-api.jar. I think this will > further improve our OSGi-friendliness, because we won't need to export > partial packages in our OSGi manifests as we currently do. > Can we also likewise move the MarkerFactory to the sl44j-api.jar? > In order to further simplify things, I think we should move the > BasicMarker.java, BasicMarkerFactory.java > MarkerIgnoringBase.java, MessageFormatter.java, Util.java classes in > package org.slf4j.impl to another package, say org.slf4j.helpers. These > classes ship in slf4j-api. > > Thus, the slf4j-api.jar would export the org.slf4j and org.slf4j.helpers > If there were a slf4j-api.jar bundle and a slf4j-nop.jar (or a slf4j-log4j12.jar...) in an OSGi runtime than the slf4j-api.jar would only need to export the org.sl4j package for user bundles to import, but it would have to import the org.slf4j.impl package from one of the binding bundle impls.
So a minimal slf4j OSGi scenario would require at least two bundles the slf4j-api.jar and an binding implementation bundle. > packages and the bindings (e.g. slf4j-nop, slf4j-log4j12, etc) would export > org.slf4j.impl package. > Great, no more 'split packages'. > I'd like to emphasize that all these changes should be transparent to our > end-users. > Right the user bundles will still only import org.sl4j. > So, WDYT? > Agree with the above package refactorings, not only do they remove the split packages, I think they make the api easier to understand as well. In addition to these I would like to pose three other techniques that could help ease issues with administration and management for us as developers and offer more agility for OSGi system administrators as well. 1. Don't offer our slf4j-api.jar as an OSGi bundle! ( This is radical but bear with me...) 2. Use the org.apache.felix maven-bundle-plugin (This is based on Peter Kreins Bnd tool) to craft our other projects as bundles. (This gets rid of maintaining a separate Manifest.mf files as everything is in the pom.xml) 3. The maven-bundle-plugin also will allow us to add packages from the classpath to the jar/bundle it creates. This is how we get the org.slf4j package in our binding jar/bundles. So when we build our binding projects to create a bundle/jar (nop,simple,...) we instruct the plugin to include the org.slf4j package in each of them. These binding jar bundles then would only export the org.slf4j package. All other packages would be private and not exported. Benefits Less files easier to maintain. Encapsulates our implementation packages. Minimal slf4j OSGi scenario would require only one bundle, which would be a choice of one of the binding implementation bundles. More complicated slfj OSGi scenarios would allow for the installation of multiple binding bundles in one OSGi runtime. With client bundles bound to their choice of binding bundles. Client bundles that did not care which binding would then only need to import org.slf4j. Others that wanted a specific binding could use something like Import-Package: org.slf4j;bundle-symbolic-name=slf4j.simple which would only bind that client bundle to a slf4j.simple bundle. Non OSGi projects would now only need to specify the bindings jar dep they needed instead of adding both it and the slf4j-api.jar to their maven deps. kind regards, John _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
