maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: fixing transfer listener in trunk
Date Mon, 12 Nov 2012 14:21:15 GMT
2012/11/12 Jason van Zyl <jason@tesla.io>:
>
> On Nov 11, 2012, at 6:52 PM, Olivier Lamy <olamy@apache.org> wrote:
>
>> 2012/11/11 Jason van Zyl <jason@tesla.io>:
>>>
>>> On Nov 11, 2012, at 2:49 AM, Olivier Lamy <olamy@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message