2012/11/12 Jason van Zyl <ja...@tesla.io>: > > On Nov 11, 2012, at 6:52 PM, Olivier Lamy <ol...@apache.org> wrote: > >> 2012/11/11 Jason van Zyl <ja...@tesla.io>: >>> >>> 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. >> 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.
Currently I'm testing integrating jansi to have colorized output, that works fine and that's fun :-) Again I don't see why we couldn't add a bit or a possibility of fun within our distribution (or at least make that easily possible) > >> 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. 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. > IMHO the number of contributors is not a good argument. How many people really contributed to sisu or aether ? And those libraries are more core part of maven than a logging framework. What you call integrators can easily change it (as core will only use slf4j api and no framework specific except maybe some sys props as it's already the case with your changes using slf4j-simple) but AFAIK that's not possible for those libraries ! I just have a look at the impact graphs in github and frankly not a lot of people contributed to those libraries. At least with log4j2 we will have a framework maintained by the Apache community so I think number of contributors will grow.. >> >>> 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: 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 >>> --------------------------------------------------------- >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> 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 > --------------------------------------------------------- > > 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 > > > > > -- 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
