Hi guys, Hope ill not be too off topic but why not using slf4j-jdk? It is pretty light since it relies on the jvm impl and it is already an interesting real logging framework (with handler/appender, filter, level...) Le 12 nov. 2012 16:20, "Jason van Zyl" <ja...@tesla.io> a écrit :
> I responded in your dogfood email. > > On Nov 12, 2012, at 9:00 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > > On Mon, Nov 12, 2012 at 8:17 AM, Jason van Zyl <ja...@tesla.io> wrote: > > > >> > >> 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. > >> > >>> 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: 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 > >> > >> > >> > >> > >> > >> > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > 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 > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > You are never dedicated to something you have complete confidence in. > No one is fanatically shouting that the sun is going to rise tomorrow. > They know it is going to rise tomorrow. When people are fanatically > dedicated to political or religious faiths or any other kind of > dogmas or goals, it's always because these dogmas or > goals are in doubt. > > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance > > > > > >
