[slf4j-dev] Rearranging classes

[Ceki Gülcü]

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