[slf4j-dev] jcl-over-slf4j module not building

[Ceki Gülcü]

At 05:37 PM 2/17/2007, John E. Conlon wrote:
> >
> > The o.s.spi package contains two interfaces, namely
> > LoggerFactoryBinder and MarkerFactoryBinder. I am not worried about
> > exposing these interfaces into the public.
> >
> >
>That makes sense.  I just committed  the change.  Project now builds
>with -Posgi flag.

Trying with the latest commit, I can confirm that the build is
successful. However, I could not get the build to complete with the
-Posgi flag. I made a number of modifications which allowed to me get
further along the way. Please also see my commit message for revision
735.

>End users will still only import o.s while adapters clients will import
>both o.s and o.s.spi.

[snip]

> > It's quite nice that we have the technical ability to package all
> > SLF4J classes within each binding. However, I am not 100% convinced
> > that doing so yields the best user experience, especially as seen by
> > developers of libraries.
> >
> > Assume Alice is the developer of some library, say La. As far as
> > Alice is concerned, imposing slf4j-api as a dependency of La is
> > acceptable while imposing a binding is not. In SLF4J 1.2, Alice has to
> > depend on a binding in La, typically slf4j-simple, and then let the
> > user change the binding. It would be more convenient if La depended on
> > slf4j-api only. This would allow the end-user to import La as is,
> > including its dependency on slf4j-api without change.
> >
>Perhaps I am not seeing it but, wouldn't it work like it always has?
>Alice for her library still imposes the slf4j-api as a dependency and
>for testing uses one of the bindings.

Exactly, the idea is to use slf4j-api as a transitive dependency and a
user-chosen dependency for testing.

> > For instance, if Bob was the author of some library, say Lb (how
> > original) which depended on La and by transitivity on slf4j-api, Bob
> > could use the SLF4J API without additional work.
> >
>Bob uses La for Lb which carries with it only the slf4j-api dependency,
>Bob then uses whatever binding he wishes for testing his Lb.
>
>Sally now builds an application from Lb and uses whatever binding she
>wants but when packaging the application for end user distribution only
>needs to add a slf4j binding to the installation zip.  (Even if she
>added the slf4j-api and the binding it should still work as expected.)

Assuming Maven 2 is used by all participants, without particular
action by Sally, slf4j-api would be packaged in the final
application along with a user-chosen binding, say slf4j-log4j12. In
that case, we would have the contents of slf4j-api project duplicated,
once in slf4j-api.jar and once in slf4j-log4j12.jar. It would most
probably work as expected, but I don't think it's good practice to
have class files duplicated.

Wishing you all a very nice week,

>John

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch