Gary, If by that you mean that it's an Apache project, I don't consider that to be a significant criterion. For me to incorporate something it matters that it's technically good and has been vetted, is mature, is well supported and has a community of users as that's how something gets vetted over time. Those are the criteria that I believe are important. Where the project resides is a matter of happenstance. I use Logback for everything and have a great relationship with Ceki so personally that's my dogfood.
On Nov 11, 2012, at 9:48 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > And then there is the whole eating your own dog food aspect of > choosing a logging framework. We've made some significant progress > over at log4j 2.0 and we are days from a beta3 release. It would be > nice to hear how we could further improve 2.0 to whet Maven's logging > appetite. > > Gary > > On Nov 11, 2012, at 5:19, Jason van Zyl <ja...@tesla.io> wrote: > >> >> On Nov 11, 2012, at 2:49 AM, Olivier Lamy <ol...@apache.org> wrote: >> >>> >>> Perso I propose a change by pointing you (you means other maven dev >>> folks too) to a branch I made somewhere but you commit code without >>> listening POV from others. >>> If you could wait to hear what other thinks that could be lovely.... >> >> I believe you do exactly what you accuse me of Olivier. You did not propose >> a change, you pointed to your branch with a terse "fixed" as if it were a >> foregone conclusion. >> >> I started the SLF4J work, I worked with Ceki to try and minimize the change, >> keep the ITs passing while preserving the existing behaviour and keeping the >> dependency size and complexity to a minimum. >> >> I've been working on restoring the behaviour and my goal, at least, was to >> reduce the possible complication of using a larger framework. The second I >> created the JIRA issue, you point at your branch and say "fixed" without any >> explanation. You used the console transfer listener not working -- and I >> admit that was annoying and I apologize for leaving it like that so long -- >> as a vehicle for adding your preferred logging framework. My goal was to >> introduce SLF4J in a minimal way, at least to start. So if that conflicts >> with your goal then that's fine but jumping in the middle of the work I'm >> doing with a change that proposes to throw away the work I did with SLF4J >> Simple is not fine. Couching it as me not taking into account a wider >> discussion as a response to me finishing what I started with a veto even >> less so. >> >> I didn't change any of the dependencies, completed the work I started and >> fixed what I broke which I believe is reasonable. >> >> If the discussion is now transitioning to users want flexible logging and >> the choice of a logging framework that's fine. But I still maintain the CLI >> use of logging can be limited and constrained while allowing integrators to >> make the small changes necessary to add flexible logging. But if we want to >> choose a framework let's look at the options, if people want to go that >> route, and select the best option. >> >> Reverting my commit will break the console transfer listener. The discussion >> about the use of a logging framework, and its choice if so decided, is not a >> foregone conclusion. So I will revert my commit in the morning when I wake >> up if you want the broken behaviour restored. But note I believe you are >> being unreasonable in that you haven't said a word until I raised the JIRA >> issue today and then took offense to me finishing my work while I was in the >> process of correcting what I broke. Obviously you were working on your >> branch while I was working on my fixes but nothing was brought up aside from >> JIRA. >> >> You have made sweeping changes in the transport and while you have made >> improvements, you have introduced several things that don't work as they did >> previously -- and I have brought these up with you directly, especially as >> it pertains to security -- I have not jumped down your throat with a veto as >> I expect you will eventually fix them because you care about users. Please >> do me the same courtesy. >> >>> >>> >>>> >>>>> >>>>> Thanks >>>>> -- >>>>> Olivier Lamy >>>>> Talend: http://coders.talend.com >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> ---------------------------------------------------------- >>>> Jason van Zyl >>>> Founder & CTO, Sonatype >>>> Founder, Apache Maven >>>> http://twitter.com/jvanzyl >>>> --------------------------------------------------------- >>>> >>>> We all have problems. How we deal with them is a measure of our worth. >>>> >>>> -- Unknown >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder & CTO, Sonatype >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
