[slf4j-dev] Rearranging classes

[John E. Conlon]

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