I agree with Anders' proposal. Let us ship 3.1 of Maven using slf4j-simple to get the change of logging api properly tried in the field.
After that, maybe targeting 3.2, we can discuss *if* we need a complex logging framework or not, and if so *which* framework would best suit the needs that Maven has. On 2012-11-11 13:35, Anders Hammar wrote: > Here's my suggestion: > > We keep the current state where we have the new logging API (slf4j) and the > System.out style implementation. Then we (Olivier?) create a JIRA ticket > for moving to a different logging implementation using a more flexible > logging framework. Then we discuss the benefits of doing that move. We > could even ask the users if it is something that people even want. > > /Anders > > > On Sun, Nov 11, 2012 at 11:19 AM, 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 >> --------------------------------------------------------- >> >> >> >> >> >> >> > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
