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 _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
