Ceki Gülcü wrote: > 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. > I don't like this class duplication either, but AFAIK given the same classloader this should not matter. The same classloader will load which ever it encounters first. (Maybe I will eat these words latter?) ;-)
a good weekend for you too, John _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
