On Mon, Nov 12, 2012 at 8:17 AM, Jason van Zyl <[email protected]> wrote:
> > On Nov 11, 2012, at 6:52 PM, Olivier Lamy <[email protected]> wrote: > > > 2012/11/11 Jason van Zyl <[email protected]>: > >> > >> 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. > > Oh maybe I should have say "possible fix" using log4j2 sorry for using > > bad word but I'm a coder not a writer and furthermore I'm not a native > > english speaker so it can happen (I have updated the jira comment). > > But I have started a discussion here (AFAIK @apache mailing list is > > the place to discuss rather than jira) > >> > >> 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 don't have any issues using slf4j as logging api but we can go > > (IMHO) a bit forward with proposing a more advanced logging > > implementation instead of the choice you made for slf4j-simple (users > > ask a more advanced logging options for a while) so it's probably the > > time to do it and take the opportunity of the good changes you made > > introducing slf4j api > > > > I would like to see that from users as I don't believe that's the case. My > specific goals were the integration of SLF4J, preserve behaviour and > provide a path forward for integrators could actually integrate the log > output and possibly for us to pick one if deemed necessary. Honestly, if I > thought we needed a logging framework from the start I would have > integrated Logback. I don't think we need that, and the use of the transfer > listener is really not the concern of the logging system, I shouldn't have > tried to use a logger in the first place there really. > > But right now if we release it in the form it is, it has the same > behaviour and we can figure out whether we want to bring in the logging > framework. > > >> > >> 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. > > > > Integrators ? Again what do you mean with that ? > > IDEs, CI systems and more sophisticated systems that embed Maven in some > form. What we do in m2eclipse for example: we need something more than > capturing the output from the console and integrating SLF4J in Maven makes > that much easier. > > > I don't understand why the default Apache Maven couldn't be able to > > propose a default advanced logging implementation. > > I think it's perfectly reasonable to talk about it, but I think from the > people that commented is that we ship this the way it is and then have that > discussion. > > > The size of the jars is around 500K so frankly I don't see that as a > > blocking issue as we already download internet :-). (and perso I'd > > like to test some ideas using jansi for possible colorized logging) > > And I don't understand why we must wait folks doing alternate > > distributions providing this feature. > > But that will be a discussion because I do not believe we should use > log4j2, I think that would be a poor choice for a number of reasons. Can you be more specific please? Gary > So I would prefer to ship this then have the discussion. > > > > >> > >> 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. > >> > > Just a matter of timing as I work on this a bit this week during my > > holidays (first I asked on log4j mailing list a new feature needed for > > maven). They fix that very quickly (thanks to log4j dev listening > > here) so I just finished my work yesterday. > > Once finished I just put that in a public space for reviews by others > > and that's it (AFAIK that's the git power) and honestly I'm not sure > > I'm the good target to be accuse doing stuff in a private area > > regarding maven... > > Again as explained previously the goal is to provide an advanced > > logging implementation in the standard Apache Maven distro. > > So I started this thread and added a comment in the jira but despite > > that you committed so even if I don't like that the only solution for > > me was a veto to be heard. > > Then we should ship this in its current form, discuss whether we need > advanced logging, and then look at the implementations. I have one using > Logback and I think that solution is more mature, and has a community and > used heavily, even by many other Apache projects. I looked at Log4j2 and > there are 2 people essentially (and one fellow with 2 commits) and I'm not > sure how the project started but I don't think it even passes Apache > Incubator standards. At first blush I don't see log4j2 as a good choice. > Hence, I agree, a discussion is required. But I think we might arrive at > the conclusion a logging framework is not necessary. > > > > >> 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. > > > > If you talk about the preemptive for get on wagon I have fixed that. > > And honestly the issue existed before that even without preemptive for > > get (see explanation/proposal on this topic here: > > http://markmail.org/message/7pswshucxc7qwtef) > > See https://jira.codehaus.org/browse/WAGON-371 (yes maybe I miss to > > release that I can do it next week) > > Yes, you fixed almost everything and that's what I was referring to. > There's always going to be stuff that doesn't work but it's a balance of > new features, moving forward and then trying to back fill. > > > > > So to be able to move forward I revert my veto. > > > > Great. > > >> > >>> > >>> > >>>> > >>>>> > >>>>> 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 > >> --------------------------------------------------------- > >> > >> > >> > >> > >> > >> > > > > > > > > -- > > 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 > --------------------------------------------------------- > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > > > > -- E-Mail: [email protected] | [email protected] JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
