At 09:07 PM 2/4/2007, John E. Conlon wrote: >Ceki Gülcü wrote: [snip]
> > 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? Good idea. [snip] >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. Yes. Trying to summarize, we would have: slf4j-api ========= Export-Package: org.slf4j, org.slf4j.helpers Import-Package: org.slf4j.impl slf4j-<impl> ============ Export-Package: org.slf4j.impl Import-Package: org.slf4j, org.slf4j.helpers Do you concur with my summary? There would be a cyclical dependence between the two jars. Do you think that could be a problem? >So a minimal slf4j OSGi scenario would require at least two bundles the >slf4j-api.jar and an binding implementation bundle. Yep. > > packages and the bindings (e.g. slf4j-nop, slf4j-log4j12, etc) would > export > > org.slf4j.impl package. Yep. >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. Indeed. >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...) If I understand you correctly, the slf4j-api.jar file would still be constructed. Correct? >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. If slf4j-api.jar is included within slf4j-<impl>.jar, wouldn't this be an OSGi-only solution? >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. Nice. >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. I'd need to see maven-bundle-plugin in action. Given that you seem to support the rearrangement, let me start with that. We can build on top of those changes to integrate steps 2 and 3 you outlined. How does that sound? >kind regards, >John -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
