On Fri, May 15, 2009 at 2:36 AM, Ceki Gulcu <c...@qos.ch> wrote: > > Henri Yandell wrote:
>> We got into this mess because there wasn't a solution and we needed >> something for Commons libraries. Personally I think there is gain in >> gently end of lifeing Commons Logging in favour of a focused logging >> project. >> >> What most of my confused email at getting at is not regarding gain but >> loss - what do we lose by doing this. The ability to do another >> release? I'm not understanding the negative. > > Stating the obvious but since you asked: You would cede control of one > part of a common component, in this case logging, to an external > entity. In most organizations such relinquishment would be > unimaginable. Things may be different with a non-profit organization > such as Apache. However, the human factor is still present. For > instance, SLF4J does not follow the same collaborative model as found > in Apache. Some developers may be turned off by such a difference. We're not actually ceding control though. I'm assuming the 0.0 or 99.0 version will be released through us etc etc. As you're an Apache committer I don't see any reason why that should be an issue. If we need to release a 0.0.0 (or whatever) later to fix an issue in the empty pom, we could. In terms of helping sfl4j gain marketshare at commons-logging's loss - more power to slf4j. You don't gain anything long term by protectionism. >> Does sfl4j also need to release a v99? I'm very susceptible to getting >> off of commons-logging and onto sfl4j (and will probably vote +1 on >> that in Commons), but are we just exchanging one dependency pain for >> another, or is there a way the issue can be solved in the long term? > > I wish I had a satisfactory answer. It is well possible that one day > version 99 would be required for SLF4J as well. It would be arrogant > and self-indulgent to say that SLF4J solves all logging API problems > once and for all. It does not. There is also no denying that with > hindsight some parts of SLF4J would be designed differently. However, > when compared to commons-logging, SLF4J's static binding mechanism is > simpler not because its designer was smarter but because it caters for > a simpler use-case. And in this particular case, simplicity implies > robustness, a highly desirable property to have in a logging system. > > Coming back to your question, there is no guarantee that SLF4J won't > bite some Apache Commons project in the tushie some time in the > future. I would however say that the likelihood for running into > trouble is lower with SLF4J than with commons-logging. Something for the Maven guys to try and solve before that day arrives I guess. Wonder what Phil et al think to making DBCP dependent on SFL4J :) Anyway +1 to the 0.0 approach. I like the 'zero'ness of it to imply that you're getting nothing, as opposed to 99 which feels more like there is something there. As long as it fills your needs, and protects from any LATEST issues it sounds like a win-win. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
