fixing transfer listener in trunk

[Olivier Lamy <ol...@apache.org>]

Hi,
As I daily use trunk as mvn version to work, I'm a bit irritate with
the current transfer listener :-)

So I have fixed using log4j2 as slf4j implementation.
See the stuff here: https://github.com/olamy/maven-3/tree/log4j2
It's simply a matter of defining a different layout for transfer
logging (which is not possible with slf4j-simple AFAIK but maybe I
miss something)

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

Re: fixing transfer listener in trunk

[Hervé BOUTEMY <he...@free.fr>]

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 <ja...@tesla.io> wrote:
> > 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.
> > 
> > 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: 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
> > ---------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Jason van Zyl <ja...@tesla.io>]

Greg,

After all these years I don't spend much time thinking about logging anymore. I use SLF4J, Logback and contribute back to those projects if I need anything.

I see that 8-9 projects at Apache are already using Logback which I think is a pretty good indicator.
 
At any rate, I think that we'll get SLF4J into Maven for the next release.  The discussion as to whether we actually need a logging framework in Maven itself is the first discussion and then if we decide that we do, then we will enter the discussion as to what framework is appropriate.

On Nov 12, 2012, at 10:22 AM, Gary Gregory <ga...@gmail.com> wrote:

> Jason,
> 
> That's all fine. I am looking for specifics to make Log4J 2 better.
> 
> Gary
> 
> On Mon, Nov 12, 2012 at 10:19 AM, Jason van Zyl <ja...@tesla.io> wrote:
> 
>> Gary,
>> 
>> If by that you mean that it's an Apache project, I don't consider that to
>> be a significant criterion. For me to incorporate something it matters that
>> it's technically good and has been vetted, is mature, is well supported and
>> has a community of users as that's how something gets vetted over time.
>> Those are the criteria that I believe are important. Where the project
>> resides is a matter of happenstance. I use Logback for everything and have
>> a great relationship with Ceki so personally that's my dogfood.
>> 
>> On Nov 11, 2012, at 9:48 AM, Gary Gregory <ga...@gmail.com> wrote:
>> 
>>> And then there is the whole eating your own dog food aspect of
>>> choosing a logging framework. We've made some significant progress
>>> over at log4j 2.0 and we are days from a beta3 release. It would be
>>> nice to hear how we could further improve 2.0 to whet Maven's logging
>>> appetite.
>>> 
>>> Gary
>>> 
>>> On Nov 11, 2012, at 5:19, Jason van Zyl <ja...@tesla.io> wrote:
>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 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: 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
>>>> ---------------------------------------------------------
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> 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
>> ---------------------------------------------------------
>> 
>> People develop abstractions by generalizing from concrete examples.
>> Every attempt to determine the correct abstraction on paper without
>> actually developing a running system is doomed to failure. No one
>> is that smart. A framework is a resuable design, so you develop it by
>> looking at the things it is supposed to be a design of. The more examples
>> you look at, the more general your framework will be.
>> 
>>  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@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
---------------------------------------------------------

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: fixing transfer listener in trunk

[Gary Gregory <ga...@gmail.com>]

Jason,

That's all fine. I am looking for specifics to make Log4J 2 better.

Gary

On Mon, Nov 12, 2012 at 10:19 AM, Jason van Zyl <ja...@tesla.io> wrote:

> Gary,
>
> If by that you mean that it's an Apache project, I don't consider that to
> be a significant criterion. For me to incorporate something it matters that
> it's technically good and has been vetted, is mature, is well supported and
> has a community of users as that's how something gets vetted over time.
> Those are the criteria that I believe are important. Where the project
> resides is a matter of happenstance. I use Logback for everything and have
> a great relationship with Ceki so personally that's my dogfood.
>
> On Nov 11, 2012, at 9:48 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> > And then there is the whole eating your own dog food aspect of
> > choosing a logging framework. We've made some significant progress
> > over at log4j 2.0 and we are days from a beta3 release. It would be
> > nice to hear how we could further improve 2.0 to whet Maven's logging
> > appetite.
> >
> > Gary
> >
> > On Nov 11, 2012, at 5:19, Jason van Zyl <ja...@tesla.io> wrote:
> >
> >>
> >> 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.
> >>
> >> 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: 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
> >> ---------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> ---------------------------------------------------------
>
> People develop abstractions by generalizing from concrete examples.
> Every attempt to determine the correct abstraction on paper without
> actually developing a running system is doomed to failure. No one
> is that smart. A framework is a resuable design, so you develop it by
> looking at the things it is supposed to be a design of. The more examples
> you look at, the more general your framework will be.
>
>   -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>
>
>
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Re: fixing transfer listener in trunk

[Jason van Zyl <ja...@tesla.io>]

Gary,

If by that you mean that it's an Apache project, I don't consider that to be a significant criterion. For me to incorporate something it matters that it's technically good and has been vetted, is mature, is well supported and has a community of users as that's how something gets vetted over time. Those are the criteria that I believe are important. Where the project resides is a matter of happenstance. I use Logback for everything and have a great relationship with Ceki so personally that's my dogfood.

On Nov 11, 2012, at 9:48 AM, Gary Gregory <ga...@gmail.com> wrote:

> And then there is the whole eating your own dog food aspect of
> choosing a logging framework. We've made some significant progress
> over at log4j 2.0 and we are days from a beta3 release. It would be
> nice to hear how we could further improve 2.0 to whet Maven's logging
> appetite.
> 
> Gary
> 
> On Nov 11, 2012, at 5:19, Jason van Zyl <ja...@tesla.io> wrote:
> 
>> 
>> 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.
>> 
>> 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: 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
>> ---------------------------------------------------------
>> 
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.

  -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 

Re: fixing transfer listener in trunk

[Gary Gregory <ga...@gmail.com>]

And then there is the whole eating your own dog food aspect of
choosing a logging framework. We've made some significant progress
over at log4j 2.0 and we are days from a beta3 release. It would be
nice to hear how we could further improve 2.0 to whet Maven's logging
appetite.

Gary

On Nov 11, 2012, at 5:19, Jason van Zyl <ja...@tesla.io> wrote:

>
> 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.
>
> 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: 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
> ---------------------------------------------------------
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Igor Fedorenko <ig...@ifedorenko.com>]

On 12-11-12 9:29 AM, Olivier Lamy wrote:
> 2012/11/12 Igor Fedorenko <ig...@ifedorenko.com>:
>>
>>
>> On 12-11-11 6:52 PM, Olivier Lamy wrote:
>>>>
>>>> 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 ? I don't understand
>>> why the default Apache Maven couldn't be able to propose a default
>>> advanced logging implementation. 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.
>>>
>>
>> m2e uses logback and switching to another slf4j provider will be
>> extremely expansive if not impossible at this point. I believe
>> downstream m2e consumers like JBoss Tools and Spring Tool Suite are in
>> the same position. We already repackage Maven as part of m2e build, so
>> removing slf4j-simple or log4j will not a problem, at least as long as
>> Maven core functionality only uses slf4j and does not depend on
>> specific logging library.
> Yup that's the case core will only use slf4j api (except some sys
> props) Perso I don't want we go in dependant logging framework model.
> So m2e wont' need to change something.
>
> AFAICS I don't see that as a real problem it's just a matter of
> removing/replacing some jars (maybe that will be more easy than you do
> today)
> Maybe I miss something ?
>

No, no problems as long as maven core only depends on slf4j.

--
Regards,
Igor

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Olivier Lamy <ol...@apache.org>]

2012/11/12 Igor Fedorenko <ig...@ifedorenko.com>:
>
>
> On 12-11-11 6:52 PM, Olivier Lamy wrote:
>>>
>>> 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 ? I don't understand
>> why the default Apache Maven couldn't be able to propose a default
>> advanced logging implementation. 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.
>>
>
> m2e uses logback and switching to another slf4j provider will be
> extremely expansive if not impossible at this point. I believe
> downstream m2e consumers like JBoss Tools and Spring Tool Suite are in
> the same position. We already repackage Maven as part of m2e build, so
> removing slf4j-simple or log4j will not a problem, at least as long as
> Maven core functionality only uses slf4j and does not depend on
> specific logging library.
Yup that's the case core will only use slf4j api (except some sys
props) Perso I don't want we go in dependant logging framework model.
So m2e wont' need to change something.

AFAICS I don't see that as a real problem it's just a matter of
removing/replacing some jars (maybe that will be more easy than you do
today)
Maybe I miss something ?

>
> --
> Regards,
> Igor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>



--
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

Re: fixing transfer listener in trunk

[Igor Fedorenko <ig...@ifedorenko.com>]

On 12-11-11 6:52 PM, Olivier Lamy wrote:
>> 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 ? I don't understand
> why the default Apache Maven couldn't be able to propose a default
> advanced logging implementation. 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.
>

m2e uses logback and switching to another slf4j provider will be
extremely expansive if not impossible at this point. I believe
downstream m2e consumers like JBoss Tools and Spring Tool Suite are in
the same position. We already repackage Maven as part of m2e build, so
removing slf4j-simple or log4j will not a problem, at least as long as
Maven core functionality only uses slf4j and does not depend on
specific logging library.

--
Regards,
Igor

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Hervé BOUTEMY <he...@free.fr>]

Le mardi 13 novembre 2012 10:09:51 Jason van Zyl a écrit :
> But again really, I believe the decision is to determine whether all this
> really necessary. I think the order of operations that folks think is
> reasonable is:
> 
> 1) Get the release out with SLF4J
> 2) Determine whether we need logging framework features
> 3) Pick one
> 
> That's what I've gathered from the discussion so I think if we plan that
> route then we can do 3.1.0, and then have the discussions and if we get to
> 3) maybe integrate that into 3.1.1 or 3.1.2.
with 6-weeks releases, this seems reasonable: I personnally need some time to 
test and make a decision based on my experience
now that there is doc about changing implementation, I can start to learn

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Jason van Zyl <ja...@tesla.io>]

On Nov 12, 2012, at 9:21 AM, Olivier Lamy <ol...@apache.org> wrote:

> 
> 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)

Sure, pretty easy with Logback: http://logback.qos.ch/manual/layouts.html#coloring

If that is really the only feature then there is another provider that just does the coloring: https://github.com/jdillon/gossip

But again really, I believe the decision is to determine whether all this really necessary. I think the order of operations that folks think is reasonable is:

1) Get the release out with SLF4J
2) Determine whether we need logging framework features
3) Pick one

That's what I've gathered from the discussion so I think if we plan that route then we can do 3.1.0, and then have the discussions and if we get to 3) maybe integrate that into 3.1.1 or 3.1.2.

Sound reasonable. 

>> 
>> 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.

Let's call it the ecosystem factor then. I consider users and contributors the most important there. As a library is nothing without users because a library with users generally has developers even if the library has reached maturity. A library with only developers and not many users isn't very valuable overall as there is really no ecosystem.

> How many people really contributed to sisu

There is only one alternative in the world for Sisu and that's Plexus. But at the core of Sisu is Guice which has a vast ecosystem. I don't think anyone will disagree it was a good choice to get off Plexus and use Sisu with the emulation layer it provides. Guice has had 5-10 developers at any given point in time and the technology is evolving in the form of Dagger by Square. So Sisu is unique in what it does, but Guice is not. We picked a solid base with a good ecosystem to build on. Maven 3.x is actually a testament to how flexible Guice is and how responsible they were to absorbing our many changes to make it work. None of this would have worked without a lot of work and help from many people. Guice is mature, has lots of users, actively developed and evolving.

In this case we are talking about the exact opposite. We have the most mature SLF4J provider with a history, users, lots of forks and pull requests and is pretty much becoming the de facto standard. On the other side you have a logging framework that no one really uses in comparison. There is a completely mature alternative.

> or aether ?

Again, what's the alternative to choose from? Both Aether and Sisu required a lot of specialized work for Maven. No one else really has time or energy to do these things. It's not commodity infrastructure like DI or logging.

> 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..
> 

That's speculation and empirically from the stats that doesn't look to be the case:

http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging

Ceki is still the largest contributor in that community and he's not there anymore.

I'm personally not in favor of giving an unproven library like log4j2 undeserved legitimacy by being used in Maven when Logback exists. No one is working on log4j really anymore so how can you say that work will continue with log4j2? And the only guy really still working on log4j is not really working on log4j2?

http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Ftrunk

I just don't see using log4j2 making much sense.

At any rate, can we agree on the plan above and table the discussion of whether we need a framework and the possibly selection of one until 3.1.1/2? That gives us time to discuss and create example implementations if the outcome of the discussion is to move forward with framework selection.

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

Re: fixing transfer listener in trunk

[Olivier Lamy <ol...@apache.org>]

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-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

Re: fixing transfer listener in trunk

[Romain Manni-Bucau <rm...@gmail.com>]

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 <ga...@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-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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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
>
>
>
>
>
>

Re: fixing transfer listener in trunk

[Jason van Zyl <ja...@tesla.io>]

I responded in your dogfood email.

On Nov 12, 2012, at 9:00 AM, Gary Gregory <ga...@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-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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@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

Re: fixing transfer listener in trunk

[Gary Gregory <ga...@gmail.com>]

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-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
>
>
>
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Re: fixing transfer listener in trunk

[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.

> 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.

> 
>> 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

Re: fixing transfer listener in trunk

[Olivier Lamy <ol...@apache.org>]

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 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 ?
I don't understand why the default Apache Maven couldn't be able to
propose a default advanced logging implementation.
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.

>
> 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.

> 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)

So to be able to move forward I revert my veto.

>
>>
>>
>>>
>>>>
>>>> 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

Re: fixing transfer listener in trunk

[Gary Gregory <ga...@gmail.com>]

Release early, release often ;)

On Mon, Nov 12, 2012 at 2:04 PM, Jason van Zyl <ja...@tesla.io> wrote:

> I think most agree that's a reasonable plan.
>
> On Nov 12, 2012, at 1:39 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> > I agree with Anders' proposal. Let us ship 3.1 of Maven using
> > slf4j-simple to get the change of logging api properly tried in the
> field.
> >
> > After that, maybe targeting 3.2, we can discuss *if* we need a complex
> > logging framework or not, and if so *which* framework would best suit
> > the needs that Maven has.
> >
> > On 2012-11-11 13:35, Anders Hammar wrote:
> >> 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 <ja...@tesla.io> wrote:
> >>
> >>>
> >>> 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.
> >>>
> >>> 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: 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
> >>> ---------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> > --
> > Dennis Lundberg
> >
> > ---------------------------------------------------------------------
> > 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
> ---------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
>  -- Buddha
>
>
>
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Re: fixing transfer listener in trunk

[Jason van Zyl <ja...@tesla.io>]

I think most agree that's a reasonable plan.

On Nov 12, 2012, at 1:39 PM, Dennis Lundberg <de...@apache.org> wrote:

> I agree with Anders' proposal. Let us ship 3.1 of Maven using
> slf4j-simple to get the change of logging api properly tried in the field.
> 
> After that, maybe targeting 3.2, we can discuss *if* we need a complex
> logging framework or not, and if so *which* framework would best suit
> the needs that Maven has.
> 
> On 2012-11-11 13:35, Anders Hammar wrote:
>> 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 <ja...@tesla.io> wrote:
>> 
>>> 
>>> 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.
>>> 
>>> 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: 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
>>> ---------------------------------------------------------
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Dennis Lundberg
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha

Re: fixing transfer listener in trunk

[Dennis Lundberg <de...@apache.org>]

I agree with Anders' proposal. Let us ship 3.1 of Maven using
slf4j-simple to get the change of logging api properly tried in the field.

After that, maybe targeting 3.2, we can discuss *if* we need a complex
logging framework or not, and if so *which* framework would best suit
the needs that Maven has.

On 2012-11-11 13:35, Anders Hammar wrote:
> 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 <ja...@tesla.io> wrote:
> 
>>
>> 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.
>>
>> 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: 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
>> ---------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Jeff Jensen <je...@upstairstechnology.com>]

On Sun, Nov 11, 2012 at 7:59 AM, Jesse McConnell
<je...@gmail.com> wrote:
> On Sun, Nov 11, 2012 at 6:35 AM, Anders Hammar <an...@hammar.net> wrote:
>> 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.
>>
>
> +1 that sounds reasonable and is akin to what we do in jetty, though
> our stdout impl has even less brains and only gets its brains when
> slf4j-api is detected in classpath
>
> cheers,
> jesse

+1
Good plan.
And having used it similarly, slf4j-simple is a good, small, default
logger choice.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Jesse McConnell <je...@gmail.com>]

On Sun, Nov 11, 2012 at 6:35 AM, Anders Hammar <an...@hammar.net> wrote:
> 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.
>

+1 that sounds reasonable and is akin to what we do in jetty, though
our stdout impl has even less brains and only gets its brains when
slf4j-api is detected in classpath

cheers,
jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: fixing transfer listener in trunk

[Anders Hammar <an...@hammar.net>]

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 <ja...@tesla.io> wrote:

>
> 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.
>
> 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: 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
> ---------------------------------------------------------
>
>
>
>
>
>
>

Re: fixing transfer listener in trunk

[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.

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: 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
---------------------------------------------------------

Re: fixing transfer listener in trunk

[Olivier Lamy <ol...@apache.org>]

2012/11/11 Jason van Zyl <ja...@tesla.io>:
>
> On Nov 10, 2012, at 5:36 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>> Hi,
>> As I daily use trunk as mvn version to work, I'm a bit irritate with
>> the current transfer listener :-)
>>
>
> Yes, I use Logback to do the same in integrations, but I would prefer not to pull in one of the larger frameworks simply to resolve the console transfer listener issue.
>
>> So I have fixed using log4j2 as slf4j implementation.
>> See the stuff here: https://github.com/olamy/maven-3/tree/log4j2
>> It's simply a matter of defining a different layout for transfer
>> logging (which is not possible with slf4j-simple AFAIK but maybe I
>> miss something)
>
> I honestly don't think it requires a logging framework, the layout is not the issue. The console transfer listener is unique in its requirements and can be dealt with accordingly. I checked in the changes that restore the console logging to its former glory, keeps the core small still using SLF4J Simple but allows extension points for integrators if they want to do anything more sophisticated. For example my Maven variant that uses Logback, or your Maven variant that uses Log4J. I would really like to try and get away with SLF4J Simple before resorting to a logging framework.

So if layout is not the issue what is the issue ?
Perso I think slf4j-simple is too simple :-) and users want for very
long time easily customizing their logging.
So adding a more advanced logging framework will help them for
customization. And this customization will be simply be changing a
configuration file (replacing/adding jars need to much manual steps
IMHO for users).
And Ralph is committer here so I'm pretty sure (or at least I hope
:-)) he will help if we have any issues.

What do you mean with "your variant" ?
Sorry but I work only on Apache Maven sources so I don't understand this point.

>
> For the following cases I have done the following:
>
> 1) Logging to the console: I simply restored the class that was there such that when logging to the console it uses System.out as it did and the download progress appears as it did.
So users are not able to simply control it as today...
>
> 2) Logging in batch mode: the batch mode transfer listener uses an SLF4J logger and the batch mode transfer listener doesn't report download progress so there is no issue. Download progress would just create a bunch of noise. The size and the speed at which it is downloaded are logged.
>
> 3) Logging to a file: same as 2) except it's all diverted to the specified file.
>
> 4) I created two protected methods in MavenCli so that integrators can supply their own console and batch transfer listeners if they wish.
Same as previous comment, users will certainly prefer control that
with modifying a configuration file
>
> I think that covers everything and avoids having to bring in Logback or Log4J.

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....


>
>>
>> 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

Re: fixing transfer listener in trunk

[Jason van Zyl <ja...@tesla.io>]

On Nov 10, 2012, at 5:36 PM, Olivier Lamy <ol...@apache.org> wrote:

> Hi,
> As I daily use trunk as mvn version to work, I'm a bit irritate with
> the current transfer listener :-)
> 

Yes, I use Logback to do the same in integrations, but I would prefer not to pull in one of the larger frameworks simply to resolve the console transfer listener issue.

> So I have fixed using log4j2 as slf4j implementation.
> See the stuff here: https://github.com/olamy/maven-3/tree/log4j2
> It's simply a matter of defining a different layout for transfer
> logging (which is not possible with slf4j-simple AFAIK but maybe I
> miss something)

I honestly don't think it requires a logging framework, the layout is not the issue. The console transfer listener is unique in its requirements and can be dealt with accordingly. I checked in the changes that restore the console logging to its former glory, keeps the core small still using SLF4J Simple but allows extension points for integrators if they want to do anything more sophisticated. For example my Maven variant that uses Logback, or your Maven variant that uses Log4J. I would really like to try and get away with SLF4J Simple before resorting to a logging framework.

For the following cases I have done the following:

1) Logging to the console: I simply restored the class that was there such that when logging to the console it uses System.out as it did and the download progress appears as it did.

2) Logging in batch mode: the batch mode transfer listener uses an SLF4J logger and the batch mode transfer listener doesn't report download progress so there is no issue. Download progress would just create a bunch of noise. The size and the speed at which it is downloaded are logged.

3) Logging to a file: same as 2) except it's all diverted to the specified file.

4) I created two protected methods in MavenCli so that integrators can supply their own console and batch transfer listeners if they wish.

I think that covers everything and avoids having to bring in Logback or Log4J.

> 
> 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