Other than you, Alan and Emmanuel chiming in, until recently, no one else provided compelling feedback. That's why I've been persistent. In the end, simplicity on the development team will probably win out here, as opposed to the cleanest solution. I must say that is rather disconcerting - this project is not, nor should ever be, about making lives easier for the development team.
On Mon, Jul 14, 2008 at 5:15 PM, Jeremy Haile <[EMAIL PROTECTED]> wrote: >> I said "thinking for alternatives.". Alan and Peter gave an >> alternative, but I didn't hear any other alternatives from other >> nay-sayers, hence my frustration. > > Their alternative seemed good to me - why do we need others? I suggested an > alternative several times: use SLF4J, not a custom logging abstraction > layer. Bundling it is a good idea if you really want it to be simple for > novice users. > >> When you have a superset of >> functionality that is dead easy to integrate, easy to use, requires >> little or no maintenance, and only enhances functionality and >> eliminates dependencies and _still_ turn it down, then there has to be >> some exceptional arguments to support the reason. > > When you have a perfectly good third-party logging abstraction framework, > you need some exceptionally good arguments to support writing another > logging abstraction layer on top of it and committing code that provides > little value and adds superfluous code to the project for everyone to > maintain and understand. (and possibly to introduce class loader issues) > > When you've got 6 or 7 people saying no, and only one person arguing for > something - it's gotta make you wonder how compelling the arguments are. > > Jeremy >
