yes, the question of which slf4j implementation we should use in Maven is a different question from how to manage progress display during transfert.
And I like > My goal was to > introduce SLF4J in a minimal way, at least to start. more than what I read previously, which gave me bad feeling without taking time to enter the discussion -- and really dig into the question, since I really don't know much about nowadays logging and didn't find myself really relevant. Sorry that I need a -1 to enter the discussion: discussion is relevant. But thank you to those who dare vote -1 these times: it's useful, even if hard to do and hard to receive. This is a good occasion to get more life in the dev community. Regards, Hervé Le dimanche 11 novembre 2012 13:35:35 Anders Hammar a écrit : > 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 <[email protected]> wrote: > > On Nov 11, 2012, at 2:49 AM, Olivier Lamy <[email protected]> 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: [email protected] > > >>> For additional commands, e-mail: [email protected] > > >> > > >> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder & CTO, Sonatype > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > --------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
