At 11:29 PM 1/31/2007, Tim Vernum wrote: >That's the way it used to be, but that presents a number of issues. > >Specifically, there are logging implementation (such as logback) that >directly >implement the API. If you push the api out into the implementation >jars, then >you start forcing other projects to bundle slf4j into their packages, >and they >need to track the slf4j team's changes themselves. >So, if Ceki (or Sebastien, or ...) fixes a bug in the API, then some >other team >that is not directly connected to the slf4j team has to do a release >of their >project. This way that problem is avoided.
Well said. >A similar problem would exist for applications teams who write their >own slf4j >implementations. The current approach just requires that they write >their >implementation and bundle it up, without having to track, or include, >any slf4j >classes. Another good point. >If you are building an application/library that depends on slf4j you >will need >to compile against slf4j-api.jar and sl4j-nop.jar > >Because the slf4j team is currently distributing most of the major >implementations, it looks a little weird to people who chose to use >one of those >implementations. But, hopefully it's clear that if/when the other >logging >projects start implementing slf4j themselves, they will need a common >-api.jar. I am quite amazed at how well you have put it. Thank you Tim. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ user mailing list [email protected] http://www.slf4j.org/mailman/listinfo/user
