You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@tesla.io> on 2012/12/01 00:20:10 UTC
Re-spinning 3.1.0
I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
I'll wait until tomorrow to re-spin.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
I'm going to start the preparation for rolling the release.
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: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
I can run a query. I would be fine using Log4J1. Well used in the field and I doubt there would be any surprises. No one suggested using it, but I think that's a more sensible choice than a project no one uses. I don't see much value in being on the bleeding edge of a logging project.
On Dec 2, 2012, at 1:20 AM, Mark Struberg <st...@yahoo.de> wrote:
>
>> Downloads from central in the last 12 months:
>>
>> Logback: 1,136,846
>> Log4J2: 6,748
>
> Do you have the number for all log4j artifacts? log4j2 just got released but is a native successor of log4j1.
>
> LieGrue,
> strub
>
>
>
>
>
>
>> ________________________________
>> From: Jason van Zyl <ja...@tesla.io>
>> To: Maven Developers List <de...@maven.apache.org>
>> Sent: Sunday, December 2, 2012 12:21 AM
>> Subject: Re: Re-spinning 3.1.0
>>
>>
>> On Dec 1, 2012, at 3:11 PM, Hervé BOUTEMY <he...@free.fr> wrote:
>>
>>> Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit :
>>>> [1]:
>>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
>>>
>>>
>>> just for side-by-side comparison:
>>> https://github.com/qos-ch/logback/graphs/contributors
>>>
>>
>> Cool, thanks. A couple more data points:
>>
>> Downloads from central in the last 12 months:
>>
>> Logback: 1,136,846
>> Log4J2: 6,748
>>
>> Projects integrating Logback:
>>
>> http://logback.qos.ch
>> 8 of which are Apache projects
>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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 do two things at once is to do neither.
-- Publilius Syrus, Roman slave, first century B.C.
Re: Re-spinning 3.1.0
Posted by Mark Struberg <st...@yahoo.de>.
>Downloads from central in the last 12 months:
>
>Logback: 1,136,846
>Log4J2: 6,748
Do you have the number for all log4j artifacts? log4j2 just got released but is a native successor of log4j1.
LieGrue,
strub
>________________________________
> From: Jason van Zyl <ja...@tesla.io>
>To: Maven Developers List <de...@maven.apache.org>
>Sent: Sunday, December 2, 2012 12:21 AM
>Subject: Re: Re-spinning 3.1.0
>
>
>On Dec 1, 2012, at 3:11 PM, Hervé BOUTEMY <he...@free.fr> wrote:
>
>> Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit :
>>> [1]:
>> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
>>
>>
>> just for side-by-side comparison:
>> https://github.com/qos-ch/logback/graphs/contributors
>>
>
>Cool, thanks. A couple more data points:
>
>Downloads from central in the last 12 months:
>
>Logback: 1,136,846
>Log4J2: 6,748
>
>Projects integrating Logback:
>
>http://logback.qos.ch
>8 of which are Apache projects
>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 3:11 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit :
>> [1]:
> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
>
>
> just for side-by-side comparison:
> https://github.com/qos-ch/logback/graphs/contributors
>
Cool, thanks. A couple more data points:
Downloads from central in the last 12 months:
Logback: 1,136,846
Log4J2: 6,748
Projects integrating Logback:
http://logback.qos.ch
8 of which are Apache projects
> ---------------------------------------------------------------------
> 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
Re: Re-spinning 3.1.0
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit :
> [1]:
http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
just for side-by-side comparison:
https://github.com/qos-ch/logback/graphs/contributors
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Arnaud Héritier <ah...@gmail.com>.
On Sat, Dec 1, 2012 at 7:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Dec 1, 2012, at 1:42 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>
> > Ok. Yes that's sure it has to be discussed. That's why I reopened the
> subject.
> > About the implementation :
> > * as a user I have really no preference, I just want the feature
> > * as a developer I played with both and for me these are just loggers
> > . We may organize a fight between Ceki and Ralph but it won't help I
> > think. I agree that log4j2 is in beta which is annoying (? Or not. We
> > are talking about a logging lib that is doing some println - but with
> > colors )
>
> It's not a fight Arnaud, I want the discussion to be about objective
> evaluation.
>
I agree. But in fact there is from my point of view no real evaluation to
do now. log4j2 is young and logback the reference implementation commonly
used.
>
> > * as PMC and ASF member I suppose I should say that our projects are
> > the best and we should privilege our own stuffs for the safety of our
> > ecosystem.
> >
>
> That, Arnaud, is nepotism. If the single strongest selection criterion
> here is nepotism then I believe there is no hope for any ecosystem. If
> nepotism above maturity, precedent, and use in the field become subordinate
> to nepotism and our view of good is bounded by only what's done at Apache
> then I believe we are truly in decline. I believe the ecosystem goes far
> beyond just what exists at Apache.
>
> Being at Apache is no guarantee for success, or health -- even with its
> powerful marketing and, at times, irrational protectionism. How is SVN
> doing compared to Git? How is Apache HTTPD doing compared to NGinx? How is
> Mina doing compared to Netty? MyBatis is thriving outside the walls of
> Apache since it left, and Logback is selected everywhere even projects at
> Apache. There are good things at Apache, there are good things outside
> Apache. I see it as an irrational train of through to have to select
> everything from Apache. To me it smacks of a form of nationalism which I
> believe is unhealthy.
>
> Honestly how did Log4J2 not have to go through the incubator? There are
> barely more than two people who have contributed, by Incubator standards
> for diversity -- if you are placing high value on the Apache way -- it
> doesn't really cut muster. I don't think it would be allowed out of the
> incubator[1] would it? Compared to something like CXF which spent how long
> in the incubator? This looks to be a completely new project.
>
> That development on Log4J stops and that the choice is not to help work on
> Logback -- which is clearly the de facto standard -- but start something
> else to me seems unwise. To use the project that Ceki started and then stop
> working on that to create something to compete with a successful project
> that Ceki created outside of Apache just seems like some really nasty
> business. I see it as an attempt to legitimize a project that has no
> traction with a project that does.
>
> If you were going to select something at work for a critical project you
> were working on would you really pick Log4J2 over Logback? I honestly don't
> think anyone would. I don't believe the mechanics of selecting and building
> software in the outside world should be anything different here. At the
> point of selection you pick best of breed to mitigate risk and integration
> problems.
>
LOL it was mainly a sarcasm this 3rd point. I should have add a smiley.
For me if we had to choose "now" log4J2 as the implementation it could be
done with this reason. I have nothing against log4J and I'm sure it will
have a great future and may be a good challenger for logback.
I may understand this reason to select it and I have nothing against it,
nor I'm afraid about it because I'm sure that like for logback we'll have
the support of the dev team.
>
> At any rate we can compare the implementations and discuss. As the RM I
> don't want to integrate a logging framework in 3.1.0.
>
+1 Fine for me.
>
> [1]:
> http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
>
> > Cheers.
> >
> > ---------
> > Arnaud
> >
> > Le 1 déc. 2012 à 09:26, Jason van Zyl <ja...@tesla.io> a écrit :
> >
> >>
> >> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com>
> wrote:
> >>
> >>> Hi Jason,
> >>>
> >>> Couldn't we have a look at olamy's log4j2 branch to see if we could
> >>> sanitize / merge it to propose at least one change for the end user
> >>> and demonstrate the interest of the change about logs : a colorized
> >>> console.
> >>
> >> Not without discussion about the implementation. To me the obvious
> choice is Logback and using Log4J2 makes no sense. Olivier disagrees so
> there will be a discussion. I've been working on the release but I plan to
> make a branch using Logback so we have a basis for discussion.
> >>
> >>>
> >>> I remember you did that in mvnsh/teslashell a long time ago (as an
> >>> extension ?) and perhaps it could be easy to add properly this feature
> >>> in 3.1.0 (otherwise it won't be before a 3.2.0).
> >>>
> >>> Myself I'm using a 3.1.0 fork with this patch and I' m really
> >>> satisfied (it's so good to quickly see highlighted warning and errors
> >>> ). I merged it back in the last 3.1.0 tag you did without issue
> >>>
> >>> Wdyt?
> >>
> >> Just as easy with Logback, the only difference being Logback is a
> mature solution. So I'm sure there's going to be a discussion.
> >>
> >>>
> >>> ---------
> >>> Arnaud
> >>>
> >>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
> >>>
> >>>> I'm done with the issues that cropped up so I'm ready to re-spin
> 3.1.0.
> >>>>
> >>>> Anyone want to add anything or discuss anything before I spin this?
> I'm not in any rush so if folks want to talk about logging we can. But
> given the fact once SLF4J initializes it can't change the implementation
> plugins integrating with Maven need to use the implementation we choose.
> This is how everything else in the world that integrates SLF4J has to
> operate so I don't really see us being any different.
> >>>>
> >>>> I'll wait until tomorrow to re-spin.
> >>>>
> >>>> 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
> >> ---------------------------------------------------------
> >>
> >> Simplex sigillum veri. (Simplicity is the seal of truth.)
> >>
> >>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> ---------------------------------------------------------
>
> I never make the mistake of arguing with people for whose opinions I have
> no respect.
>
> -- Edward Gibbon
>
>
>
>
>
>
--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Re: Re-spinning 3.1.0
Posted by Gary Gregory <ga...@gmail.com>.
Great emails here. My mention of log4j2 is to get a hard core customer
- maven - in order to make log4j2 better. Whether that is in the best
interest of Maven users and developers is a different question which
you guys know best. I'm fine with Maven jumping on the logback
bandwagon. If there are technical issues with maven using log4j2, we'd
love to hear about them.
Gary
On Dec 1, 2012, at 15:17, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Dec 1, 2012, at 10:23 AM, Benson Margulies <bi...@gmail.com> wrote:
>
>> On Sat, Dec 1, 2012 at 1:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>>>
>>> On Dec 1, 2012, at 1:42 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>
>>>> Ok. Yes that's sure it has to be discussed. That's why I reopened the subject.
>>>> About the implementation :
>>>> * as a user I have really no preference, I just want the feature
>>>> * as a developer I played with both and for me these are just loggers
>>>> . We may organize a fight between Ceki and Ralph but it won't help I
>>>> think. I agree that log4j2 is in beta which is annoying (? Or not. We
>>>> are talking about a logging lib that is doing some println - but with
>>>> colors )
>>>
>>> It's not a fight Arnaud, I want the discussion to be about objective evaluation.
>>>
>>>> * as PMC and ASF member I suppose I should say that our projects are
>>>> the best and we should privilege our own stuffs for the safety of our
>>>> ecosystem.
>>>>
>>>
>>> That, Arnaud, is nepotism. If the single strongest selection criterion here is nepotism then I believe there is no hope for any ecosystem. If nepotism above maturity, precedent, and use in the field become subordinate to nepotism and our view of good is bounded by only what's done at Apache then I believe we are truly in decline. I believe the ecosystem goes far beyond just what exists at Apache.
>>
>> I wouldn't say, 'nepotism,' but I agree with the bottom line of
>> Jason's argument.
>
> I would say it's pretty close the definition: favoritism granted to relatives regardless of merit. Log4J2 is completely unproven in the world at large and at this particular junction. It may well become the best logging framework with the most vibrant community. It's not today but today is what we're talking about. Not what might be. I'm just pointing out that I believe Arnaud's criterion for selection of the library being present at Apache is invalid. That you would be hard pressed to find anyone, anywhere who today would pick Log4J2 over Logback.
>
> My counter argument to that line of reasoning is what happened to the people who picked MINA? Netty is crushing it. MINA doesn't appear particular active or innovative[1]. Twitter hired a Netty developer, not a MINA developer. Maybe it could have turned out differently and MINA would be crushing it. The point is where a project sits is no indication of its potential success, health or otherwise. You pick something based on its merits when you need it.
>
> And yes Log4J2 being used in Maven would help it greatly. Maven is one of the most widely known and used projects in the Java ecosystem. It would be the first thing that showed up on their powered by page, and they would cite Maven to other projects as a reason to use it. Absolutely guaranteed. If you're telling me that hasn't crossed their minds I'd say that's a naive perspective. No one uses your stuff if they can't find others who use it. I doubt you pick libraries no one else uses. To try and catapult a project through a relationship to me is an abuse in an ostensibly merit-based community.
>
> I'm not going to veto the use of Log4J2 but I'm definitely going to force people to think about why they would choose it. I once picked a library because I thought it would be a great addition to Maven and thought it would grow and eventually be great because it was at Apache. That library was called Jelly (sorry James :-)). That wasn't exactly a great choice. It could have gone otherwise but again my point is you don't look at what-ifs and make the decision based on the information available today. Logback is a successful project today that lots of people use, including projects here.
>
> [1]: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fmina
>
>> The ASF is like Harvard College: "Every tub on its
>> own bottom." We pay attention to licensing issues, but we don't go far
>> out of our way to use the output of another ASF project rather than
>> something that happens to come from somewhere else. Jason, Arnaud is
>> not, as far as I know, quoting any policy prescription of the ASF. The
>> ASF is not trying to be an 'ecosystem', especially a closed ecosystem.
>> It is trying to provide a home for projects that follow its
>> principles.
>>
>> My contribution to the hot air fund here is this: I think that the
>> idea of 'competition' in open source is often misguided. There's
>> generally plenty of room for many different variations on many
>> different themes. Many build tools, many logging frameworks, many
>> foundations. I don't think that a decision by Maven to use the new
>> log4j will give them any meaningful boost towards success in Apache
>> terms (being a vibrant community), nor will deciding to look elsewhere
>> give them a significant ding.
>>
>> ---------------------------------------------------------------------
>> 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
> ---------------------------------------------------------
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 10:23 AM, Benson Margulies <bi...@gmail.com> wrote:
> On Sat, Dec 1, 2012 at 1:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>>
>> On Dec 1, 2012, at 1:42 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>>
>>> Ok. Yes that's sure it has to be discussed. That's why I reopened the subject.
>>> About the implementation :
>>> * as a user I have really no preference, I just want the feature
>>> * as a developer I played with both and for me these are just loggers
>>> . We may organize a fight between Ceki and Ralph but it won't help I
>>> think. I agree that log4j2 is in beta which is annoying (? Or not. We
>>> are talking about a logging lib that is doing some println - but with
>>> colors )
>>
>> It's not a fight Arnaud, I want the discussion to be about objective evaluation.
>>
>>> * as PMC and ASF member I suppose I should say that our projects are
>>> the best and we should privilege our own stuffs for the safety of our
>>> ecosystem.
>>>
>>
>> That, Arnaud, is nepotism. If the single strongest selection criterion here is nepotism then I believe there is no hope for any ecosystem. If nepotism above maturity, precedent, and use in the field become subordinate to nepotism and our view of good is bounded by only what's done at Apache then I believe we are truly in decline. I believe the ecosystem goes far beyond just what exists at Apache.
>
> I wouldn't say, 'nepotism,' but I agree with the bottom line of
> Jason's argument.
I would say it's pretty close the definition: favoritism granted to relatives regardless of merit. Log4J2 is completely unproven in the world at large and at this particular junction. It may well become the best logging framework with the most vibrant community. It's not today but today is what we're talking about. Not what might be. I'm just pointing out that I believe Arnaud's criterion for selection of the library being present at Apache is invalid. That you would be hard pressed to find anyone, anywhere who today would pick Log4J2 over Logback.
My counter argument to that line of reasoning is what happened to the people who picked MINA? Netty is crushing it. MINA doesn't appear particular active or innovative[1]. Twitter hired a Netty developer, not a MINA developer. Maybe it could have turned out differently and MINA would be crushing it. The point is where a project sits is no indication of its potential success, health or otherwise. You pick something based on its merits when you need it.
And yes Log4J2 being used in Maven would help it greatly. Maven is one of the most widely known and used projects in the Java ecosystem. It would be the first thing that showed up on their powered by page, and they would cite Maven to other projects as a reason to use it. Absolutely guaranteed. If you're telling me that hasn't crossed their minds I'd say that's a naive perspective. No one uses your stuff if they can't find others who use it. I doubt you pick libraries no one else uses. To try and catapult a project through a relationship to me is an abuse in an ostensibly merit-based community.
I'm not going to veto the use of Log4J2 but I'm definitely going to force people to think about why they would choose it. I once picked a library because I thought it would be a great addition to Maven and thought it would grow and eventually be great because it was at Apache. That library was called Jelly (sorry James :-)). That wasn't exactly a great choice. It could have gone otherwise but again my point is you don't look at what-ifs and make the decision based on the information available today. Logback is a successful project today that lots of people use, including projects here.
[1]: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fmina
> The ASF is like Harvard College: "Every tub on its
> own bottom." We pay attention to licensing issues, but we don't go far
> out of our way to use the output of another ASF project rather than
> something that happens to come from somewhere else. Jason, Arnaud is
> not, as far as I know, quoting any policy prescription of the ASF. The
> ASF is not trying to be an 'ecosystem', especially a closed ecosystem.
> It is trying to provide a home for projects that follow its
> principles.
>
> My contribution to the hot air fund here is this: I think that the
> idea of 'competition' in open source is often misguided. There's
> generally plenty of room for many different variations on many
> different themes. Many build tools, many logging frameworks, many
> foundations. I don't think that a decision by Maven to use the new
> log4j will give them any meaningful boost towards success in Apache
> terms (being a vibrant community), nor will deciding to look elsewhere
> give them a significant ding.
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
Re: Re-spinning 3.1.0
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Dec 1, 2012 at 1:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Dec 1, 2012, at 1:42 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>
>> Ok. Yes that's sure it has to be discussed. That's why I reopened the subject.
>> About the implementation :
>> * as a user I have really no preference, I just want the feature
>> * as a developer I played with both and for me these are just loggers
>> . We may organize a fight between Ceki and Ralph but it won't help I
>> think. I agree that log4j2 is in beta which is annoying (? Or not. We
>> are talking about a logging lib that is doing some println - but with
>> colors )
>
> It's not a fight Arnaud, I want the discussion to be about objective evaluation.
>
>> * as PMC and ASF member I suppose I should say that our projects are
>> the best and we should privilege our own stuffs for the safety of our
>> ecosystem.
>>
>
> That, Arnaud, is nepotism. If the single strongest selection criterion here is nepotism then I believe there is no hope for any ecosystem. If nepotism above maturity, precedent, and use in the field become subordinate to nepotism and our view of good is bounded by only what's done at Apache then I believe we are truly in decline. I believe the ecosystem goes far beyond just what exists at Apache.
I wouldn't say, 'nepotism,' but I agree with the bottom line of
Jason's argument. The ASF is like Harvard College: "Every tub on its
own bottom." We pay attention to licensing issues, but we don't go far
out of our way to use the output of another ASF project rather than
something that happens to come from somewhere else. Jason, Arnaud is
not, as far as I know, quoting any policy prescription of the ASF. The
ASF is not trying to be an 'ecosystem', especially a closed ecosystem.
It is trying to provide a home for projects that follow its
principles.
My contribution to the hot air fund here is this: I think that the
idea of 'competition' in open source is often misguided. There's
generally plenty of room for many different variations on many
different themes. Many build tools, many logging frameworks, many
foundations. I don't think that a decision by Maven to use the new
log4j will give them any meaningful boost towards success in Apache
terms (being a vibrant community), nor will deciding to look elsewhere
give them a significant ding.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 1:42 AM, Arnaud Héritier <ah...@gmail.com> wrote:
> Ok. Yes that's sure it has to be discussed. That's why I reopened the subject.
> About the implementation :
> * as a user I have really no preference, I just want the feature
> * as a developer I played with both and for me these are just loggers
> . We may organize a fight between Ceki and Ralph but it won't help I
> think. I agree that log4j2 is in beta which is annoying (? Or not. We
> are talking about a logging lib that is doing some println - but with
> colors )
It's not a fight Arnaud, I want the discussion to be about objective evaluation.
> * as PMC and ASF member I suppose I should say that our projects are
> the best and we should privilege our own stuffs for the safety of our
> ecosystem.
>
That, Arnaud, is nepotism. If the single strongest selection criterion here is nepotism then I believe there is no hope for any ecosystem. If nepotism above maturity, precedent, and use in the field become subordinate to nepotism and our view of good is bounded by only what's done at Apache then I believe we are truly in decline. I believe the ecosystem goes far beyond just what exists at Apache.
Being at Apache is no guarantee for success, or health -- even with its powerful marketing and, at times, irrational protectionism. How is SVN doing compared to Git? How is Apache HTTPD doing compared to NGinx? How is Mina doing compared to Netty? MyBatis is thriving outside the walls of Apache since it left, and Logback is selected everywhere even projects at Apache. There are good things at Apache, there are good things outside Apache. I see it as an irrational train of through to have to select everything from Apache. To me it smacks of a form of nationalism which I believe is unhealthy.
Honestly how did Log4J2 not have to go through the incubator? There are barely more than two people who have contributed, by Incubator standards for diversity -- if you are placing high value on the Apache way -- it doesn't really cut muster. I don't think it would be allowed out of the incubator[1] would it? Compared to something like CXF which spent how long in the incubator? This looks to be a completely new project.
That development on Log4J stops and that the choice is not to help work on Logback -- which is clearly the de facto standard -- but start something else to me seems unwise. To use the project that Ceki started and then stop working on that to create something to compete with a successful project that Ceki created outside of Apache just seems like some really nasty business. I see it as an attempt to legitimize a project that has no traction with a project that does.
If you were going to select something at work for a critical project you were working on would you really pick Log4J2 over Logback? I honestly don't think anyone would. I don't believe the mechanics of selecting and building software in the outside world should be anything different here. At the point of selection you pick best of breed to mitigate risk and integration problems.
At any rate we can compare the implementations and discuss. As the RM I don't want to integrate a logging framework in 3.1.0.
[1]: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2
> Cheers.
>
> ---------
> Arnaud
>
> Le 1 déc. 2012 à 09:26, Jason van Zyl <ja...@tesla.io> a écrit :
>
>>
>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>>
>>> Hi Jason,
>>>
>>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>>> sanitize / merge it to propose at least one change for the end user
>>> and demonstrate the interest of the change about logs : a colorized
>>> console.
>>
>> Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion.
>>
>>>
>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>> extension ?) and perhaps it could be easy to add properly this feature
>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>
>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>> satisfied (it's so good to quickly see highlighted warning and errors
>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>
>>> Wdyt?
>>
>> Just as easy with Logback, the only difference being Logback is a mature solution. So I'm sure there's going to be a discussion.
>>
>>>
>>> ---------
>>> Arnaud
>>>
>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>
>>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>>
>>>> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
>>>>
>>>> I'll wait until tomorrow to re-spin.
>>>>
>>>> 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
>> ---------------------------------------------------------
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I have no respect.
-- Edward Gibbon
Re: Re-spinning 3.1.0
Posted by Stuart McCulloch <mc...@gmail.com>.
On 1 Dec 2012, at 10:07, Mark Struberg wrote:
> There is btw out of the box @InjectLogger support for Log4j2 in guice. A few projects are using this already without problems it seems.
Depends what you mean by 'out-of-the-box', Guice only provides built-in support for @Inject of j.u.l.Logger (http://code.google.com/p/google-guice/wiki/BuiltInBindings). With Sisu we add support for @Inject org.slf4j.Logger, and for something like @InjectLogger you'll need a logging extension like http://onami.incubator.apache.org/logging/ that involves registering a custom injector (http://code.google.com/p/google-guice/wiki/CustomInjections).
HTH
> LieGrue,
> strub
>
> ----- Original Message -----
>> From: Arnaud Héritier <ah...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Saturday, December 1, 2012 10:42 AM
>> Subject: Re: Re-spinning 3.1.0
>>
>> Ok. Yes that's sure it has to be discussed. That's why I reopened the
>> subject.
>> About the implementation :
>> * as a user I have really no preference, I just want the feature
>> * as a developer I played with both and for me these are just loggers
>> . We may organize a fight between Ceki and Ralph but it won't help I
>> think. I agree that log4j2 is in beta which is annoying (? Or not. We
>> are talking about a logging lib that is doing some println - but with
>> colors )
>> * as PMC and ASF member I suppose I should say that our projects are
>> the best and we should privilege our own stuffs for the safety of our
>> ecosystem.
>>
>> Cheers.
>>
>> ---------
>> Arnaud
>>
>> Le 1 déc. 2012 à 09:26, Jason van Zyl <ja...@tesla.io> a écrit :
>>
>>>
>>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com>
>> wrote:
>>>
>>>> Hi Jason,
>>>>
>>>> Couldn't we have a look at olamy's log4j2 branch to see if we
>> could
>>>> sanitize / merge it to propose at least one change for the end user
>>>> and demonstrate the interest of the change about logs : a colorized
>>>> console.
>>>
>>> Not without discussion about the implementation. To me the obvious choice
>> is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a
>> discussion. I've been working on the release but I plan to make a branch
>> using Logback so we have a basis for discussion.
>>>
>>>>
>>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>>> extension ?) and perhaps it could be easy to add properly this feature
>>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>>
>>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>>> satisfied (it's so good to quickly see highlighted warning and
>> errors
>>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>>
>>>> Wdyt?
>>>
>>> Just as easy with Logback, the only difference being Logback is a mature
>> solution. So I'm sure there's going to be a discussion.
>>>
>>>>
>>>> ---------
>>>> Arnaud
>>>>
>>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>>
>>>>> I'm done with the issues that cropped up so I'm ready to
>> re-spin 3.1.0.
>>>>>
>>>>> Anyone want to add anything or discuss anything before I spin this?
>> I'm not in any rush so if folks want to talk about logging we can. But given
>> the fact once SLF4J initializes it can't change the implementation plugins
>> integrating with Maven need to use the implementation we choose. This is how
>> everything else in the world that integrates SLF4J has to operate so I don't
>> really see us being any different.
>>>>>
>>>>> I'll wait until tomorrow to re-spin.
>>>>>
>>>>> 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
>>> ---------------------------------------------------------
>>>
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Mark Struberg <st...@yahoo.de>.
There is btw out of the box @InjectLogger support for Log4j2 in guice. A few projects are using this already without problems it seems.
LieGrue,
strub
----- Original Message -----
> From: Arnaud Héritier <ah...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, December 1, 2012 10:42 AM
> Subject: Re: Re-spinning 3.1.0
>
> Ok. Yes that's sure it has to be discussed. That's why I reopened the
> subject.
> About the implementation :
> * as a user I have really no preference, I just want the feature
> * as a developer I played with both and for me these are just loggers
> . We may organize a fight between Ceki and Ralph but it won't help I
> think. I agree that log4j2 is in beta which is annoying (? Or not. We
> are talking about a logging lib that is doing some println - but with
> colors )
> * as PMC and ASF member I suppose I should say that our projects are
> the best and we should privilege our own stuffs for the safety of our
> ecosystem.
>
> Cheers.
>
> ---------
> Arnaud
>
> Le 1 déc. 2012 à 09:26, Jason van Zyl <ja...@tesla.io> a écrit :
>
>>
>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com>
> wrote:
>>
>>> Hi Jason,
>>>
>>> Couldn't we have a look at olamy's log4j2 branch to see if we
> could
>>> sanitize / merge it to propose at least one change for the end user
>>> and demonstrate the interest of the change about logs : a colorized
>>> console.
>>
>> Not without discussion about the implementation. To me the obvious choice
> is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a
> discussion. I've been working on the release but I plan to make a branch
> using Logback so we have a basis for discussion.
>>
>>>
>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>> extension ?) and perhaps it could be easy to add properly this feature
>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>
>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>> satisfied (it's so good to quickly see highlighted warning and
> errors
>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>
>>> Wdyt?
>>
>> Just as easy with Logback, the only difference being Logback is a mature
> solution. So I'm sure there's going to be a discussion.
>>
>>>
>>> ---------
>>> Arnaud
>>>
>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>
>>>> I'm done with the issues that cropped up so I'm ready to
> re-spin 3.1.0.
>>>>
>>>> Anyone want to add anything or discuss anything before I spin this?
> I'm not in any rush so if folks want to talk about logging we can. But given
> the fact once SLF4J initializes it can't change the implementation plugins
> integrating with Maven need to use the implementation we choose. This is how
> everything else in the world that integrates SLF4J has to operate so I don't
> really see us being any different.
>>>>
>>>> I'll wait until tomorrow to re-spin.
>>>>
>>>> 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
>> ---------------------------------------------------------
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Arnaud Héritier <ah...@gmail.com>.
Ok. Yes that's sure it has to be discussed. That's why I reopened the subject.
About the implementation :
* as a user I have really no preference, I just want the feature
* as a developer I played with both and for me these are just loggers
. We may organize a fight between Ceki and Ralph but it won't help I
think. I agree that log4j2 is in beta which is annoying (? Or not. We
are talking about a logging lib that is doing some println - but with
colors )
* as PMC and ASF member I suppose I should say that our projects are
the best and we should privilege our own stuffs for the safety of our
ecosystem.
Cheers.
---------
Arnaud
Le 1 déc. 2012 à 09:26, Jason van Zyl <ja...@tesla.io> a écrit :
>
> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>
>> Hi Jason,
>>
>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>> sanitize / merge it to propose at least one change for the end user
>> and demonstrate the interest of the change about logs : a colorized
>> console.
>
> Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion.
>
>>
>> I remember you did that in mvnsh/teslashell a long time ago (as an
>> extension ?) and perhaps it could be easy to add properly this feature
>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>
>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>> satisfied (it's so good to quickly see highlighted warning and errors
>> ). I merged it back in the last 3.1.0 tag you did without issue
>>
>> Wdyt?
>
> Just as easy with Logback, the only difference being Logback is a mature solution. So I'm sure there's going to be a discussion.
>
>>
>> ---------
>> Arnaud
>>
>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>
>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>
>>> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
>>>
>>> I'll wait until tomorrow to re-spin.
>>>
>>> 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
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
If a script or plugin was provided to make changing the implementation easy I think that would be better. That can be made as simple. I think shipping optional components is generally a bad practice. It would be like shipping all the wagon/aether implementations to let people pick. Not really scalable and I don't think users really care that much and with event spies users are responsible for adding the components.
On Dec 1, 2012, at 2:22 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Dec 1, 2012, at 2:17 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>> On Dec 1, 2012, at 1:44 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>
>>>>>
>>>>> I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
>>>>>
>>>> if documented that's not really complicated.
>>>>
>>>
>>> So the process would be:
>>>
>> Did you check build distrib link I provide or git branch ?
>>> - downloads the new implementation
>> no. implementations are already here in separate directories.
>>> - change the configuration
>> no, default configuration files for 3 impl are here.
>>> - use a command line parameter
>> only configure MAVEN_OPTS envvar (not having to repeat that for each
>> maven invocation)
>>
>> and modify it if you want to try an other.
>>
>
> I don't think we should avoid the discussion of picking an implementation by shipping them all.
>
> I'm not in favour of shipping all the implementations.
>
>>
>>>
>>>> this could be nice for ci servers to get logs easily.
>>>
>>> A single good implementation would also work.
>>>
>>>> We already have eventspy to intercept build informations so why not
>>>> having something else for logs.
>>>
>>> The mechanism for the event spy is just putting an extension on the classpath. If you wanted to leverage the existing mechanism you can just put the JARs in the ${MAVEN_HOME}/lib/ext directory along with making your configuration available, but you're going to have to remove the other SLF4J implementation or you're going to get the duplicate binding exception. Not a huge deal.
>>>
>>> So you can already add a new implementation of SLF4J right now using the mechanism that exists without anything additional. No modification of the classwords configuration or a command line parameters which gives it parity with the event spy if that's what you're looking for.
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> A man enjoys his work when he understands the whole and when he
>>> is responsible for the quality of the whole
>>>
>>> -- Christopher Alexander, A Pattern Language
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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
> ---------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
>
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
I never make the mistake of arguing with people for whose opinions I have no respect.
-- Edward Gibbon
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
Olivier can clarify but appears to me to ship all implementations with configurations to let the user flip.
I don't think anyone can honestly justify shipping Log4J2 by default, I think Logback is appropriate so he's trying to accommodate everyone's PoV. But I still think we have to pick an implementation.
On Dec 1, 2012, at 2:37 PM, Benson Margulies <bi...@gmail.com> wrote:
> On Sat, Dec 1, 2012 at 5:32 PM, Jason van Zyl <ja...@tesla.io> wrote:
>>
>> On Dec 1, 2012, at 2:27 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>>
>>> I just try to make more than one happy so what is your reason ?
>>>
>>
>> That shipping multiple implementations means we have to support them for no particular reason. I think that setup is fairly convoluted for users, and still we have really determined it's really of any use to the average user. Downloading some things and placing them in the ext/ directory for the odd time someone is going to need it I think works perfectly fine.
>>
>> We should pick one implementation by default like we do with anything else. Logging is not special.
>
> Wait, didn't I read Olivier to write that he does *not* propose to
> ship more than one, merely to offer a quickie shortcut to turning on
> another if someone drops it into place? Or am I confused?
>
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> A party which is not afraid of letting culture,
>> business, and welfare go to ruin completely can
>> be omnipotent for a while.
>>
>> -- Jakob Burckhardt
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Re-spinning 3.1.0
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Dec 1, 2012 at 5:32 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Dec 1, 2012, at 2:27 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>>
>> I just try to make more than one happy so what is your reason ?
>>
>
> That shipping multiple implementations means we have to support them for no particular reason. I think that setup is fairly convoluted for users, and still we have really determined it's really of any use to the average user. Downloading some things and placing them in the ext/ directory for the odd time someone is going to need it I think works perfectly fine.
>
> We should pick one implementation by default like we do with anything else. Logging is not special.
Wait, didn't I read Olivier to write that he does *not* propose to
ship more than one, merely to offer a quickie shortcut to turning on
another if someone drops it into place? Or am I confused?
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
>
> -- Jakob Burckhardt
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
I'm going to hack on the Aether branch for the rest of the day, I'll check in tomorrow morning to see what others think about the release.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A language that doesn’t affect the way you think about programming is not worth knowing.
-- Alan Perlis
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 2:27 PM, Olivier Lamy <ol...@apache.org> wrote:
>
> I just try to make more than one happy so what is your reason ?
>
That shipping multiple implementations means we have to support them for no particular reason. I think that setup is fairly convoluted for users, and still we have really determined it's really of any use to the average user. Downloading some things and placing them in the ext/ directory for the odd time someone is going to need it I think works perfectly fine.
We should pick one implementation by default like we do with anything else. Logging is not special.
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
Re: Re-spinning 3.1.0
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/1 Jason van Zyl <ja...@tesla.io>:
>
> On Dec 1, 2012, at 2:17 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>> On Dec 1, 2012, at 1:44 PM, Olivier Lamy <ol...@apache.org> wrote:
>>>
>>>>>
>>>>> I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
>>>>>
>>>> if documented that's not really complicated.
>>>>
>>>
>>> So the process would be:
>>>
>> Did you check build distrib link I provide or git branch ?
>>> - downloads the new implementation
>> no. implementations are already here in separate directories.
>>> - change the configuration
>> no, default configuration files for 3 impl are here.
>>> - use a command line parameter
>> only configure MAVEN_OPTS envvar (not having to repeat that for each
>> maven invocation)
>>
>> and modify it if you want to try an other.
>>
>
> I don't think we should avoid the discussion of picking an implementation by shipping them all.
>
> I'm not in favour of shipping all the implementations.
I just try to make more than one happy so what is your reason ?
>
>>
>>>
>>>> this could be nice for ci servers to get logs easily.
>>>
>>> A single good implementation would also work.
>>>
>>>> We already have eventspy to intercept build informations so why not
>>>> having something else for logs.
>>>
>>> The mechanism for the event spy is just putting an extension on the classpath. If you wanted to leverage the existing mechanism you can just put the JARs in the ${MAVEN_HOME}/lib/ext directory along with making your configuration available, but you're going to have to remove the other SLF4J implementation or you're going to get the duplicate binding exception. Not a huge deal.
>>>
>>> So you can already add a new implementation of SLF4J right now using the mechanism that exists without anything additional. No modification of the classwords configuration or a command line parameters which gives it parity with the event spy if that's what you're looking for.
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> A man enjoys his work when he understands the whole and when he
>>> is responsible for the quality of the whole
>>>
>>> -- Christopher Alexander, A Pattern Language
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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
> ---------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
>
>
>
--
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: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 2:17 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>> On Dec 1, 2012, at 1:44 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>>>
>>>> I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
>>>>
>>> if documented that's not really complicated.
>>>
>>
>> So the process would be:
>>
> Did you check build distrib link I provide or git branch ?
>> - downloads the new implementation
> no. implementations are already here in separate directories.
>> - change the configuration
> no, default configuration files for 3 impl are here.
>> - use a command line parameter
> only configure MAVEN_OPTS envvar (not having to repeat that for each
> maven invocation)
>
> and modify it if you want to try an other.
>
I don't think we should avoid the discussion of picking an implementation by shipping them all.
I'm not in favour of shipping all the implementations.
>
>>
>>> this could be nice for ci servers to get logs easily.
>>
>> A single good implementation would also work.
>>
>>> We already have eventspy to intercept build informations so why not
>>> having something else for logs.
>>
>> The mechanism for the event spy is just putting an extension on the classpath. If you wanted to leverage the existing mechanism you can just put the JARs in the ${MAVEN_HOME}/lib/ext directory along with making your configuration available, but you're going to have to remove the other SLF4J implementation or you're going to get the duplicate binding exception. Not a huge deal.
>>
>> So you can already add a new implementation of SLF4J right now using the mechanism that exists without anything additional. No modification of the classwords configuration or a command line parameters which gives it parity with the event spy if that's what you're looking for.
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> A man enjoys his work when he understands the whole and when he
>> is responsible for the quality of the whole
>>
>> -- Christopher Alexander, A Pattern Language
>>
>>
>>
>>
>>
>
>
>
> --
> 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
---------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Re-spinning 3.1.0
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/1 Jason van Zyl <ja...@tesla.io>:
> On Dec 1, 2012, at 1:44 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>>>
>>> I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
>>>
>> if documented that's not really complicated.
>>
>
> So the process would be:
>
Did you check build distrib link I provide or git branch ?
> - downloads the new implementation
no. implementations are already here in separate directories.
> - change the configuration
no, default configuration files for 3 impl are here.
> - use a command line parameter
only configure MAVEN_OPTS envvar (not having to repeat that for each
maven invocation)
and modify it if you want to try an other.
>
>> this could be nice for ci servers to get logs easily.
>
> A single good implementation would also work.
>
>> We already have eventspy to intercept build informations so why not
>> having something else for logs.
>
> The mechanism for the event spy is just putting an extension on the classpath. If you wanted to leverage the existing mechanism you can just put the JARs in the ${MAVEN_HOME}/lib/ext directory along with making your configuration available, but you're going to have to remove the other SLF4J implementation or you're going to get the duplicate binding exception. Not a huge deal.
>
> So you can already add a new implementation of SLF4J right now using the mechanism that exists without anything additional. No modification of the classwords configuration or a command line parameters which gives it parity with the event spy if that's what you're looking for.
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
> -- Christopher Alexander, A Pattern Language
>
>
>
>
>
--
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: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 1:44 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>> I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
>>
> if documented that's not really complicated.
>
So the process would be:
- downloads the new implementation
- change the configuration
- use a command line parameter
> this could be nice for ci servers to get logs easily.
A single good implementation would also work.
> We already have eventspy to intercept build informations so why not
> having something else for logs.
The mechanism for the event spy is just putting an extension on the classpath. If you wanted to leverage the existing mechanism you can just put the JARs in the ${MAVEN_HOME}/lib/ext directory along with making your configuration available, but you're going to have to remove the other SLF4J implementation or you're going to get the duplicate binding exception. Not a huge deal.
So you can already add a new implementation of SLF4J right now using the mechanism that exists without anything additional. No modification of the classwords configuration or a command line parameters which gives it parity with the event spy if that's what you're looking for.
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
Re: Re-spinning 3.1.0
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Dec 1, 2012 at 4:44 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>
>> On Dec 1, 2012, at 12:39 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> Why do we have to force our users to a specific logging implementation
>>> than we choose ?
>>
>> My counter argument is why don't we? That is the pattern of most forms of integration because trying to account for many implementations interacting together have unknown side affects. Just because you can do something doesn't mean it's useful.
>>
>>> We can propose variants and at least one as a workaround to maybe fix
>>> sonar issue.
>>>
>>> So what I do in the branch called dynamic-logging-impl is a "dynamic"
>>> way of loading the implementation users prefers (default is log4j2).
>>> It's just a matter of modifying MAVEN_OPTS="-Dmaven.logger.impl=log4j2
>>> or slf4-simple or logback" (and thanks to our home made "osgi"
>>> classworld :-) )
>>
>> The point again is just because you can do doesn't mean it's useful. How many times does someone really need a different implementation? Just because someone wants something doesn't mean you should give it to them. I believe just allowing anything isn't actually helpful to anyone.
>>
>>>
>>> Note: with this implementation is possible to use any other slf4j impl
>>> you want (IMHO good enhancement for ci servers which want to route
>>> logs somewhere)
>>> It's just a matter of adding a realm in m2.conf
>>>
>>> [thegreat-new-a-la-mode-slf4j-impl]
>>> load path to my great new slf4j impl/*.jar
>>>
>>> Then
>>> MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"
>>>
>>
>> I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
>>
> if documented that's not really complicated.
>
> this could be nice for ci servers to get logs easily.
> We already have eventspy to intercept build informations so why not
> having something else for logs.
>
>
>> I think we need to pick one and go with it. If users want something different they can change the structure of the distribution.
>>
>>> Anyway just tested with sonar and
>>> [ERROR] Failed to execute goal
>>> org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
>>> project hello-world: Can not execute Sonar:
>>> ch.qos.logback.classic.LoggerContext cannot be cast to
>>> ch.qos.logback.classic.LoggerContext
>>> I always love such classloader message :-)
>>>
>>> So I need to investigate a little bit more but not so far from having
>>> that for sonar
>>> BTW works fine for classic use case.
>>>
>>> If you want to test that a build is available here:
>>> http://people.apache.org/~olamy/maven/dynamic-logging-impl/
>>>
>>> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>>>
>>>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>>
>>>>> Hi Jason,
>>>>>
>>>>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>>>>> sanitize / merge it to propose at least one change for the end user
>>>>> and demonstrate the interest of the change about logs : a colorized
>>>>> console.
>>>>
>>>> Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion.
>>>>
>>>>>
>>>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>>>> extension ?) and perhaps it could be easy to add properly this feature
>>>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>>>
>>>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>>>> satisfied (it's so good to quickly see highlighted warning and errors
>>>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>>>
>>>>> Wdyt?
>>>>
>>>> Just as easy with Logback, the only difference being Logback is a mature solution. So I'm sure there's going to be a discussion.
>>>>
>>>>>
>>>>> ---------
>>>>> Arnaud
>>>>>
>>>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>>>
>>>>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>>>>
>>>>>> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
I think that 'Maven, the command-line tool' should have one(*) logging back end.
I think that 'Maven, the embeddable build system' should have, as an
advantage, the ability to log to any slf4j backend that the embedding
application cares to use.
In between is a gray area, where a 'power user' might read
documentation that explains how to reconfigure the usual command-line
directory tree to use a different back end, via Olivier's mechanism.
Doing so would come with a disclaimer. But I don't see how it has to
be a gigantic disclaimer. If it works for embedding to pick any slf4j
back end, then it's hard for me to see gigantic risks to a user in
reconfiguring the command-line package.
I am fine with rolling 3.1.0(-?) as-is, and then pull in Olivier's
work and reviewing it, or pulling it in first, FWIW.
>>>>>>
>>>>>> I'll wait until tomorrow to re-spin.
>>>>>>
>>>>>> 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
>>>> ---------------------------------------------------------
>>>>
>>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> ---------------------------------------------------------
>>
>> What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
>>
>> -- Paul Graham
>>
>>
>>
>>
>>
>
> That's not because we disagree that you are right.
> -- Winston Churchill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/1 Jason van Zyl <ja...@tesla.io>:
>
> On Dec 1, 2012, at 12:39 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>> Hi,
>>
>> Why do we have to force our users to a specific logging implementation
>> than we choose ?
>
> My counter argument is why don't we? That is the pattern of most forms of integration because trying to account for many implementations interacting together have unknown side affects. Just because you can do something doesn't mean it's useful.
>
>> We can propose variants and at least one as a workaround to maybe fix
>> sonar issue.
>>
>> So what I do in the branch called dynamic-logging-impl is a "dynamic"
>> way of loading the implementation users prefers (default is log4j2).
>> It's just a matter of modifying MAVEN_OPTS="-Dmaven.logger.impl=log4j2
>> or slf4-simple or logback" (and thanks to our home made "osgi"
>> classworld :-) )
>
> The point again is just because you can do doesn't mean it's useful. How many times does someone really need a different implementation? Just because someone wants something doesn't mean you should give it to them. I believe just allowing anything isn't actually helpful to anyone.
>
>>
>> Note: with this implementation is possible to use any other slf4j impl
>> you want (IMHO good enhancement for ci servers which want to route
>> logs somewhere)
>> It's just a matter of adding a realm in m2.conf
>>
>> [thegreat-new-a-la-mode-slf4j-impl]
>> load path to my great new slf4j impl/*.jar
>>
>> Then
>> MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"
>>
>
> I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
>
if documented that's not really complicated.
this could be nice for ci servers to get logs easily.
We already have eventspy to intercept build informations so why not
having something else for logs.
> I think we need to pick one and go with it. If users want something different they can change the structure of the distribution.
>
>> Anyway just tested with sonar and
>> [ERROR] Failed to execute goal
>> org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
>> project hello-world: Can not execute Sonar:
>> ch.qos.logback.classic.LoggerContext cannot be cast to
>> ch.qos.logback.classic.LoggerContext
>> I always love such classloader message :-)
>>
>> So I need to investigate a little bit more but not so far from having
>> that for sonar
>> BTW works fine for classic use case.
>>
>> If you want to test that a build is available here:
>> http://people.apache.org/~olamy/maven/dynamic-logging-impl/
>>
>> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>>
>>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>
>>>> Hi Jason,
>>>>
>>>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>>>> sanitize / merge it to propose at least one change for the end user
>>>> and demonstrate the interest of the change about logs : a colorized
>>>> console.
>>>
>>> Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion.
>>>
>>>>
>>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>>> extension ?) and perhaps it could be easy to add properly this feature
>>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>>
>>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>>> satisfied (it's so good to quickly see highlighted warning and errors
>>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>>
>>>> Wdyt?
>>>
>>> Just as easy with Logback, the only difference being Logback is a mature solution. So I'm sure there's going to be a discussion.
>>>
>>>>
>>>> ---------
>>>> Arnaud
>>>>
>>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>>
>>>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>>>
>>>>> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
>>>>>
>>>>> I'll wait until tomorrow to re-spin.
>>>>>
>>>>> 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
>>> ---------------------------------------------------------
>>>
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
>
>
>
>
That's not because we disagree that you are right.
-- Winston Churchill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 2:24 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>> How many times does someone really need a different implementation?
>
> Sorry Jason, thats bollocks and you know it.
>
You looked at the the question and presumed an answer. You're assuming my is never. The answer is not very often, which begs the question of balance between creating a convoluted mechanism for accommodating the infrequency of that requirement versus having something simpler, less magic, smaller and working for most cases.
>
>
>> That is the pattern of most forms of
>> integration because trying to account for many implementations interacting
>> together have unknown side affects.
>
>
> You are wrong and right at the same time:
> Yes it's broken and has unknown side effects.
It's not broken, it has side effects as all things do.
> Thanks for finally acknowledging this. So why the hell do we force a single established framework to any user at all?
As that's generally what most do in order to avoid having to support all combinations of things which is untenable.
> That's the reason why any sane container I know doesn't do that.
>
I see most containers picking defaults.
>
> Again: the easy solution would be a slf4j-MojoLogging bridge and all is fine.
>
> Plugins which like to use slf4j can simply use this bridge and all is fine. Other plugins will not be hurt.
>
Then implement it Mark and demonstrate, you keep talking about this but the whole while haven't demonstrated any of your theory.
Olivier and I may be disagreeing but we're both doing work and making implementations.
As I said before I am not in a terrible rush so implement what you think works best and show us.
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Jason van Zyl <ja...@tesla.io>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Saturday, December 1, 2012 10:31 PM
>> Subject: Re: Re-spinning 3.1.0
>>
>>
>> On Dec 1, 2012, at 12:39 PM, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> Why do we have to force our users to a specific logging implementation
>>> than we choose ?
>>
>> My counter argument is why don't we? That is the pattern of most forms of
>> integration because trying to account for many implementations interacting
>> together have unknown side affects. Just because you can do something
>> doesn't mean it's useful.
>>
>>> We can propose variants and at least one as a workaround to maybe fix
>>> sonar issue.
>>>
>>> So what I do in the branch called dynamic-logging-impl is a
>> "dynamic"
>>> way of loading the implementation users prefers (default is log4j2).
>>> It's just a matter of modifying
>> MAVEN_OPTS="-Dmaven.logger.impl=log4j2
>>> or slf4-simple or logback" (and thanks to our home made
>> "osgi"
>>> classworld :-) )
>>
>> The point again is just because you can do doesn't mean it's useful. How
>> many times does someone really need a different implementation? Just because
>> someone wants something doesn't mean you should give it to them. I believe
>> just allowing anything isn't actually helpful to anyone.
>>
>>>
>>> Note: with this implementation is possible to use any other slf4j impl
>>> you want (IMHO good enhancement for ci servers which want to route
>>> logs somewhere)
>>> It's just a matter of adding a realm in m2.conf
>>>
>>> [thegreat-new-a-la-mode-slf4j-impl]
>>> load path to my great new slf4j impl/*.jar
>>>
>>> Then
>>>
>> MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"
>>>
>>
>> I don't think that's particularly easy and additionally opens us up to
>> having to specifically support any SLF4J implementation which I don't think
>> is wise.
>>
>> I think we need to pick one and go with it. If users want something different
>> they can change the structure of the distribution.
>>
>>> Anyway just tested with sonar and
>>> [ERROR] Failed to execute goal
>>> org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
>>> project hello-world: Can not execute Sonar:
>>> ch.qos.logback.classic.LoggerContext cannot be cast to
>>> ch.qos.logback.classic.LoggerContext
>>> I always love such classloader message :-)
>>>
>>> So I need to investigate a little bit more but not so far from having
>>> that for sonar
>>> BTW works fine for classic use case.
>>>
>>> If you want to test that a build is available here:
>>> http://people.apache.org/~olamy/maven/dynamic-logging-impl/
>>>
>>> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>>>
>>>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier
>> <ah...@gmail.com> wrote:
>>>>
>>>>> Hi Jason,
>>>>>
>>>>> Couldn't we have a look at olamy's log4j2 branch to see if
>> we could
>>>>> sanitize / merge it to propose at least one change for the end user
>>>>> and demonstrate the interest of the change about logs : a colorized
>>>>> console.
>>>>
>>>> Not without discussion about the implementation. To me the obvious
>> choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there
>> will be a discussion. I've been working on the release but I plan to make a
>> branch using Logback so we have a basis for discussion.
>>>>
>>>>>
>>>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>>>> extension ?) and perhaps it could be easy to add properly this
>> feature
>>>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>>>
>>>>> Myself I'm using a 3.1.0 fork with this patch and I' m
>> really
>>>>> satisfied (it's so good to quickly see highlighted warning and
>> errors
>>>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>>>
>>>>> Wdyt?
>>>>
>>>> Just as easy with Logback, the only difference being Logback is a
>> mature solution. So I'm sure there's going to be a discussion.
>>>>
>>>>>
>>>>> ---------
>>>>> Arnaud
>>>>>
>>>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a
>> écrit :
>>>>>
>>>>>> I'm done with the issues that cropped up so I'm ready
>> to re-spin 3.1.0.
>>>>>>
>>>>>> Anyone want to add anything or discuss anything before I spin
>> this? I'm not in any rush so if folks want to talk about logging we can. But
>> given the fact once SLF4J initializes it can't change the implementation
>> plugins integrating with Maven need to use the implementation we choose. This is
>> how everything else in the world that integrates SLF4J has to operate so I
>> don't really see us being any different.
>>>>>>
>>>>>> I'll wait until tomorrow to re-spin.
>>>>>>
>>>>>> 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
>>>> ---------------------------------------------------------
>>>>
>>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> ---------------------------------------------------------
>>
>> What matters is not ideas, but the people who have them. Good people can fix bad
>> ideas, but good ideas can't save bad people.
>>
>> -- Paul Graham
>>
>
> ---------------------------------------------------------------------
> 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 know what we are, but know not what we may be.
-- Shakespeare
Re: Re-spinning 3.1.0
Posted by Mark Struberg <st...@yahoo.de>.
> How many times does someone really need a different implementation?
Sorry Jason, thats bollocks and you know it.
> That is the pattern of most forms of
> integration because trying to account for many implementations interacting
> together have unknown side affects.
You are wrong and right at the same time:
Yes it's broken and has unknown side effects. Thanks for finally acknowledging this. So why the hell do we force a single established framework to any user at all? That's the reason why any sane container I know doesn't do that.
Again: the easy solution would be a slf4j-MojoLogging bridge and all is fine.
Plugins which like to use slf4j can simply use this bridge and all is fine. Other plugins will not be hurt.
LieGrue,
strub
----- Original Message -----
> From: Jason van Zyl <ja...@tesla.io>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, December 1, 2012 10:31 PM
> Subject: Re: Re-spinning 3.1.0
>
>
> On Dec 1, 2012, at 12:39 PM, Olivier Lamy <ol...@apache.org> wrote:
>
>> Hi,
>>
>> Why do we have to force our users to a specific logging implementation
>> than we choose ?
>
> My counter argument is why don't we? That is the pattern of most forms of
> integration because trying to account for many implementations interacting
> together have unknown side affects. Just because you can do something
> doesn't mean it's useful.
>
>> We can propose variants and at least one as a workaround to maybe fix
>> sonar issue.
>>
>> So what I do in the branch called dynamic-logging-impl is a
> "dynamic"
>> way of loading the implementation users prefers (default is log4j2).
>> It's just a matter of modifying
> MAVEN_OPTS="-Dmaven.logger.impl=log4j2
>> or slf4-simple or logback" (and thanks to our home made
> "osgi"
>> classworld :-) )
>
> The point again is just because you can do doesn't mean it's useful. How
> many times does someone really need a different implementation? Just because
> someone wants something doesn't mean you should give it to them. I believe
> just allowing anything isn't actually helpful to anyone.
>
>>
>> Note: with this implementation is possible to use any other slf4j impl
>> you want (IMHO good enhancement for ci servers which want to route
>> logs somewhere)
>> It's just a matter of adding a realm in m2.conf
>>
>> [thegreat-new-a-la-mode-slf4j-impl]
>> load path to my great new slf4j impl/*.jar
>>
>> Then
>>
> MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"
>>
>
> I don't think that's particularly easy and additionally opens us up to
> having to specifically support any SLF4J implementation which I don't think
> is wise.
>
> I think we need to pick one and go with it. If users want something different
> they can change the structure of the distribution.
>
>> Anyway just tested with sonar and
>> [ERROR] Failed to execute goal
>> org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
>> project hello-world: Can not execute Sonar:
>> ch.qos.logback.classic.LoggerContext cannot be cast to
>> ch.qos.logback.classic.LoggerContext
>> I always love such classloader message :-)
>>
>> So I need to investigate a little bit more but not so far from having
>> that for sonar
>> BTW works fine for classic use case.
>>
>> If you want to test that a build is available here:
>> http://people.apache.org/~olamy/maven/dynamic-logging-impl/
>>
>> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>>
>>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier
> <ah...@gmail.com> wrote:
>>>
>>>> Hi Jason,
>>>>
>>>> Couldn't we have a look at olamy's log4j2 branch to see if
> we could
>>>> sanitize / merge it to propose at least one change for the end user
>>>> and demonstrate the interest of the change about logs : a colorized
>>>> console.
>>>
>>> Not without discussion about the implementation. To me the obvious
> choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there
> will be a discussion. I've been working on the release but I plan to make a
> branch using Logback so we have a basis for discussion.
>>>
>>>>
>>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>>> extension ?) and perhaps it could be easy to add properly this
> feature
>>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>>
>>>> Myself I'm using a 3.1.0 fork with this patch and I' m
> really
>>>> satisfied (it's so good to quickly see highlighted warning and
> errors
>>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>>
>>>> Wdyt?
>>>
>>> Just as easy with Logback, the only difference being Logback is a
> mature solution. So I'm sure there's going to be a discussion.
>>>
>>>>
>>>> ---------
>>>> Arnaud
>>>>
>>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a
> écrit :
>>>>
>>>>> I'm done with the issues that cropped up so I'm ready
> to re-spin 3.1.0.
>>>>>
>>>>> Anyone want to add anything or discuss anything before I spin
> this? I'm not in any rush so if folks want to talk about logging we can. But
> given the fact once SLF4J initializes it can't change the implementation
> plugins integrating with Maven need to use the implementation we choose. This is
> how everything else in the world that integrates SLF4J has to operate so I
> don't really see us being any different.
>>>>>
>>>>> I'll wait until tomorrow to re-spin.
>>>>>
>>>>> 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
>>> ---------------------------------------------------------
>>>
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them. Good people can fix bad
> ideas, but good ideas can't save bad people.
>
> -- Paul Graham
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 12:39 PM, Olivier Lamy <ol...@apache.org> wrote:
> Hi,
>
> Why do we have to force our users to a specific logging implementation
> than we choose ?
My counter argument is why don't we? That is the pattern of most forms of integration because trying to account for many implementations interacting together have unknown side affects. Just because you can do something doesn't mean it's useful.
> We can propose variants and at least one as a workaround to maybe fix
> sonar issue.
>
> So what I do in the branch called dynamic-logging-impl is a "dynamic"
> way of loading the implementation users prefers (default is log4j2).
> It's just a matter of modifying MAVEN_OPTS="-Dmaven.logger.impl=log4j2
> or slf4-simple or logback" (and thanks to our home made "osgi"
> classworld :-) )
The point again is just because you can do doesn't mean it's useful. How many times does someone really need a different implementation? Just because someone wants something doesn't mean you should give it to them. I believe just allowing anything isn't actually helpful to anyone.
>
> Note: with this implementation is possible to use any other slf4j impl
> you want (IMHO good enhancement for ci servers which want to route
> logs somewhere)
> It's just a matter of adding a realm in m2.conf
>
> [thegreat-new-a-la-mode-slf4j-impl]
> load path to my great new slf4j impl/*.jar
>
> Then
> MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"
>
I don't think that's particularly easy and additionally opens us up to having to specifically support any SLF4J implementation which I don't think is wise.
I think we need to pick one and go with it. If users want something different they can change the structure of the distribution.
> Anyway just tested with sonar and
> [ERROR] Failed to execute goal
> org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
> project hello-world: Can not execute Sonar:
> ch.qos.logback.classic.LoggerContext cannot be cast to
> ch.qos.logback.classic.LoggerContext
> I always love such classloader message :-)
>
> So I need to investigate a little bit more but not so far from having
> that for sonar
> BTW works fine for classic use case.
>
> If you want to test that a build is available here:
> http://people.apache.org/~olamy/maven/dynamic-logging-impl/
>
> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
>>
>> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>>
>>> Hi Jason,
>>>
>>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>>> sanitize / merge it to propose at least one change for the end user
>>> and demonstrate the interest of the change about logs : a colorized
>>> console.
>>
>> Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion.
>>
>>>
>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>> extension ?) and perhaps it could be easy to add properly this feature
>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>
>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>> satisfied (it's so good to quickly see highlighted warning and errors
>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>
>>> Wdyt?
>>
>> Just as easy with Logback, the only difference being Logback is a mature solution. So I'm sure there's going to be a discussion.
>>
>>>
>>> ---------
>>> Arnaud
>>>
>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>
>>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>>
>>>> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
>>>>
>>>> I'll wait until tomorrow to re-spin.
>>>>
>>>> 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
>> ---------------------------------------------------------
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------
What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
Re: Re-spinning 3.1.0
Posted by Jeff Jensen <je...@upstairstechnology.com>.
On Sat, Dec 1, 2012 at 2:39 PM, Olivier Lamy <ol...@apache.org> wrote:
> Hi,
>
> Why do we have to force our users to a specific logging implementation
> than we choose ?
>
Doesn't the product have to establish a default? Isn't that the one
"forced" on the users?
Substitution of the default for alternate implementation is a feature.
I think first establish a solid default and then consider a feature that
enables changing by the user.
The default has not been decided yet, as far as I can discern. Call for a
vote on the default logger implementation.
We can propose variants and at least one as a workaround to maybe fix
> sonar issue.
>
> So what I do in the branch called dynamic-logging-impl is a "dynamic"
> way of loading the implementation users prefers (default is log4j2).
> It's just a matter of modifying MAVEN_OPTS="-Dmaven.logger.impl=log4j2
> or slf4-simple or logback" (and thanks to our home made "osgi"
> classworld :-) )
>
> Note: with this implementation is possible to use any other slf4j impl
> you want (IMHO good enhancement for ci servers which want to route
> logs somewhere)
> It's just a matter of adding a realm in m2.conf
>
> [thegreat-new-a-la-mode-slf4j-impl]
> load path to my great new slf4j impl/*.jar
>
> Then
> MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"
>
> Anyway just tested with sonar and
> [ERROR] Failed to execute goal
> org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
> project hello-world: Can not execute Sonar:
> ch.qos.logback.classic.LoggerContext cannot be cast to
> ch.qos.logback.classic.LoggerContext
> I always love such classloader message :-)
>
> So I need to investigate a little bit more but not so far from having
> that for sonar
> BTW works fine for classic use case.
>
> If you want to test that a build is available here:
> http://people.apache.org/~olamy/maven/dynamic-logging-impl/
>
> 2012/12/1 Jason van Zyl <ja...@tesla.io>:
> >
> > On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com>
> wrote:
> >
> >> Hi Jason,
> >>
> >> Couldn't we have a look at olamy's log4j2 branch to see if we could
> >> sanitize / merge it to propose at least one change for the end user
> >> and demonstrate the interest of the change about logs : a colorized
> >> console.
> >
> > Not without discussion about the implementation. To me the obvious
> choice is Logback and using Log4J2 makes no sense. Olivier disagrees so
> there will be a discussion. I've been working on the release but I plan to
> make a branch using Logback so we have a basis for discussion.
> >
> >>
> >> I remember you did that in mvnsh/teslashell a long time ago (as an
> >> extension ?) and perhaps it could be easy to add properly this feature
> >> in 3.1.0 (otherwise it won't be before a 3.2.0).
> >>
> >> Myself I'm using a 3.1.0 fork with this patch and I' m really
> >> satisfied (it's so good to quickly see highlighted warning and errors
> >> ). I merged it back in the last 3.1.0 tag you did without issue
> >>
> >> Wdyt?
> >
> > Just as easy with Logback, the only difference being Logback is a mature
> solution. So I'm sure there's going to be a discussion.
> >
> >>
> >> ---------
> >> Arnaud
> >>
> >> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
> >>
> >>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
> >>>
> >>> Anyone want to add anything or discuss anything before I spin this?
> I'm not in any rush so if folks want to talk about logging we can. But
> given the fact once SLF4J initializes it can't change the implementation
> plugins integrating with Maven need to use the implementation we choose.
> This is how everything else in the world that integrates SLF4J has to
> operate so I don't really see us being any different.
> >>>
> >>> I'll wait until tomorrow to re-spin.
> >>>
> >>> 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
> > ---------------------------------------------------------
> >
> > Simplex sigillum veri. (Simplicity is the seal of truth.)
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Re-spinning 3.1.0
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
Why do we have to force our users to a specific logging implementation
than we choose ?
We can propose variants and at least one as a workaround to maybe fix
sonar issue.
So what I do in the branch called dynamic-logging-impl is a "dynamic"
way of loading the implementation users prefers (default is log4j2).
It's just a matter of modifying MAVEN_OPTS="-Dmaven.logger.impl=log4j2
or slf4-simple or logback" (and thanks to our home made "osgi"
classworld :-) )
Note: with this implementation is possible to use any other slf4j impl
you want (IMHO good enhancement for ci servers which want to route
logs somewhere)
It's just a matter of adding a realm in m2.conf
[thegreat-new-a-la-mode-slf4j-impl]
load path to my great new slf4j impl/*.jar
Then
MAVEN_OPTS="-Dmaven.logger.impl=thegreat-new-a-la-mode-slf4j-impl"
Anyway just tested with sonar and
[ERROR] Failed to execute goal
org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on
project hello-world: Can not execute Sonar:
ch.qos.logback.classic.LoggerContext cannot be cast to
ch.qos.logback.classic.LoggerContext
I always love such classloader message :-)
So I need to investigate a little bit more but not so far from having
that for sonar
BTW works fine for classic use case.
If you want to test that a build is available here:
http://people.apache.org/~olamy/maven/dynamic-logging-impl/
2012/12/1 Jason van Zyl <ja...@tesla.io>:
>
> On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com> wrote:
>
>> Hi Jason,
>>
>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>> sanitize / merge it to propose at least one change for the end user
>> and demonstrate the interest of the change about logs : a colorized
>> console.
>
> Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion.
>
>>
>> I remember you did that in mvnsh/teslashell a long time ago (as an
>> extension ?) and perhaps it could be easy to add properly this feature
>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>
>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>> satisfied (it's so good to quickly see highlighted warning and errors
>> ). I merged it back in the last 3.1.0 tag you did without issue
>>
>> Wdyt?
>
> Just as easy with Logback, the only difference being Logback is a mature solution. So I'm sure there's going to be a discussion.
>
>>
>> ---------
>> Arnaud
>>
>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>
>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>
>>> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
>>>
>>> I'll wait until tomorrow to re-spin.
>>>
>>> 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
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Dec 1, 2012, at 12:17 AM, Arnaud Héritier <ah...@gmail.com> wrote:
> Hi Jason,
>
> Couldn't we have a look at olamy's log4j2 branch to see if we could
> sanitize / merge it to propose at least one change for the end user
> and demonstrate the interest of the change about logs : a colorized
> console.
Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion.
>
> I remember you did that in mvnsh/teslashell a long time ago (as an
> extension ?) and perhaps it could be easy to add properly this feature
> in 3.1.0 (otherwise it won't be before a 3.2.0).
>
> Myself I'm using a 3.1.0 fork with this patch and I' m really
> satisfied (it's so good to quickly see highlighted warning and errors
> ). I merged it back in the last 3.1.0 tag you did without issue
>
> Wdyt?
Just as easy with Logback, the only difference being Logback is a mature solution. So I'm sure there's going to be a discussion.
>
> ---------
> Arnaud
>
> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>
>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>
>> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
>>
>> I'll wait until tomorrow to re-spin.
>>
>> 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
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Re-spinning 3.1.0
Posted by Hervé BOUTEMY <he...@free.fr>.
I'm doing more comparison for myself, that can be useful for others
for the config format:
http://logback.qos.ch/manual/configuration.html
vs
http://logging.apache.org/log4j/2.x/manual/configuration.html
I don't see much difference
Notice there is no dtd nor schema for both
I like having some help while hacking configuration files, like auto-completion.
Is there something available in log4j2 or logback for this?
Or will I have to learn the XML structure of each by trial-error?
Le dimanche 2 décembre 2012 00:30:48 Hervé BOUTEMY a écrit :
> Le samedi 1 décembre 2012 12:10:43 Stuart McCulloch a écrit :
> > You might want to take a look at
> > http://logback.qos.ch/manual/layouts.html#coloring for additional
> > background
>
> thank you Stuart, really useful
>
> I made the same research for log4j2, to continue my personal comparison and
> found "highlight" in http://logging.apache.org/log4j/2.x/manual/layouts.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 1 décembre 2012 12:10:43 Stuart McCulloch a écrit :
> You might want to take a look at
> http://logback.qos.ch/manual/layouts.html#coloring for additional
> background
thank you Stuart, really useful
I made the same research for log4j2, to continue my personal comparison and
found "highlight" in http://logging.apache.org/log4j/2.x/manual/layouts.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Stuart McCulloch <mc...@gmail.com>.
On 1 Dec 2012, at 08:40, Hervé BOUTEMY wrote:
> I just created and fixed MNG-5395 and MNG-5396, which are logger names
> enhancements from the actual values that will give value even with slf4j-
> simple
>
> These should be a starting point for more global discussion about our logging
> conventions then fixed in our global codebase, since IMHO, these issues show
> how we didn't use the logger names until now then we have a lot of place where
> our logging pratice is not good
>
> Of course, I'm interested in colorized output, but since it has impact on
> logging implementation choice, which will require a strong discussion, this
> can't be done for the moment :|
You might want to take a look at http://logback.qos.ch/manual/layouts.html#coloring for additional background
> Regards,
>
> Hervé
>
> Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit :
>> Hi Jason,
>>
>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>> sanitize / merge it to propose at least one change for the end user
>> and demonstrate the interest of the change about logs : a colorized
>> console.
>>
>> I remember you did that in mvnsh/teslashell a long time ago (as an
>> extension ?) and perhaps it could be easy to add properly this feature
>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>
>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>> satisfied (it's so good to quickly see highlighted warning and errors
>> ). I merged it back in the last 3.1.0 tag you did without issue
>>
>> Wdyt?
>>
>> ---------
>> Arnaud
>>
>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>>>
>>> Anyone want to add anything or discuss anything before I spin this? I'm
>>> not in any rush so if folks want to talk about logging we can. But given
>>> the fact once SLF4J initializes it can't change the implementation
>>> plugins integrating with Maven need to use the implementation we choose.
>>> This is how everything else in the world that integrates SLF4J has to
>>> operate so I don't really see us being any different.
>>>
>>> I'll wait until tomorrow to re-spin.
>>>
>>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Hervé BOUTEMY <he...@free.fr>.
I just created and fixed MNG-5395 and MNG-5396, which are logger names
enhancements from the actual values that will give value even with slf4j-
simple
These should be a starting point for more global discussion about our logging
conventions then fixed in our global codebase, since IMHO, these issues show
how we didn't use the logger names until now then we have a lot of place where
our logging pratice is not good
Of course, I'm interested in colorized output, but since it has impact on
logging implementation choice, which will require a strong discussion, this
can't be done for the moment :|
Regards,
Hervé
Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit :
> Hi Jason,
>
> Couldn't we have a look at olamy's log4j2 branch to see if we could
> sanitize / merge it to propose at least one change for the end user
> and demonstrate the interest of the change about logs : a colorized
> console.
>
> I remember you did that in mvnsh/teslashell a long time ago (as an
> extension ?) and perhaps it could be easy to add properly this feature
> in 3.1.0 (otherwise it won't be before a 3.2.0).
>
> Myself I'm using a 3.1.0 fork with this patch and I' m really
> satisfied (it's so good to quickly see highlighted warning and errors
> ). I merged it back in the last 3.1.0 tag you did without issue
>
> Wdyt?
>
> ---------
> Arnaud
>
> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
> > I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
> >
> > Anyone want to add anything or discuss anything before I spin this? I'm
> > not in any rush so if folks want to talk about logging we can. But given
> > the fact once SLF4J initializes it can't change the implementation
> > plugins integrating with Maven need to use the implementation we choose.
> > This is how everything else in the world that integrates SLF4J has to
> > operate so I don't really see us being any different.
> >
> > I'll wait until tomorrow to re-spin.
> >
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Arnaud Héritier <ah...@gmail.com>.
I agree. That doesn't change that log4j2 is young compared to logback
and I could understand that people could prefer to select it over
log4j for that reason. Myself I have really no preference
The best I suppose will be to open a thread to discuss about pros and
cons of each ones and then vote. (For me all of this is probably to
much to just select which lines if codes will do our println with
colors but I think it will be better for the community to be sure to
ear and respect the choice of developers...)
---------
Arnaud
Le 1 déc. 2012 à 14:00, Olivier Lamy <ol...@apache.org> a écrit :
> 2012/12/1 Gary Gregory <ga...@gmail.com>:
>> Log4j2 supports color consoles, even on Windows. Is this support
>> incomplete? I know, I know,still in beta.
> sometimes version naming doesn't have a real added value (IMHO)
>
> some projects use 0.1.x model without any alpha/beta qualifier
> some others use beta/alpha qualifier
>
> so frankly it's a just sometimes a "marketing" choice :-)
> Hey we lived here very long with something called
> plexus-container-default 1.0-alpha-x and we released a lot of versions
> of maven 2.x with that :-)
>
>>
>> Gary
>>
>> On Dec 1, 2012, at 5:05, Mark Struberg <st...@yahoo.de> wrote:
>>
>>> sounds great, have Oliviers branch running locally myself without issues.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Arnaud Héritier <ah...@gmail.com>
>>>> To: Maven Developers List <de...@maven.apache.org>
>>>> Cc:
>>>> Sent: Saturday, December 1, 2012 9:17 AM
>>>> Subject: Re: Re-spinning 3.1.0
>>>>
>>>> Hi Jason,
>>>>
>>>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>>>> sanitize / merge it to propose at least one change for the end user
>>>> and demonstrate the interest of the change about logs : a colorized
>>>> console.
>>>>
>>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>>> extension ?) and perhaps it could be easy to add properly this feature
>>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>>
>>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>>> satisfied (it's so good to quickly see highlighted warning and errors
>>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>>
>>>> Wdyt?
>>>>
>>>> ---------
>>>> Arnaud
>>>>
>>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>>
>>>>> I'm done with the issues that cropped up so I'm ready to re-spin
>>>> 3.1.0.
>>>>>
>>>>> Anyone want to add anything or discuss anything before I spin this? I'm
>>>> not in any rush so if folks want to talk about logging we can. But given the
>>>> fact once SLF4J initializes it can't change the implementation plugins
>>>> integrating with Maven need to use the implementation we choose. This is how
>>>> everything else in the world that integrates SLF4J has to operate so I don't
>>>> really see us being any different.
>>>>>
>>>>> I'll wait until tomorrow to re-spin.
>>>>>
>>>>> 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
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/1 Gary Gregory <ga...@gmail.com>:
> Log4j2 supports color consoles, even on Windows. Is this support
> incomplete? I know, I know,still in beta.
sometimes version naming doesn't have a real added value (IMHO)
some projects use 0.1.x model without any alpha/beta qualifier
some others use beta/alpha qualifier
so frankly it's a just sometimes a "marketing" choice :-)
Hey we lived here very long with something called
plexus-container-default 1.0-alpha-x and we released a lot of versions
of maven 2.x with that :-)
>
> Gary
>
> On Dec 1, 2012, at 5:05, Mark Struberg <st...@yahoo.de> wrote:
>
>> sounds great, have Oliviers branch running locally myself without issues.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Arnaud Héritier <ah...@gmail.com>
>>> To: Maven Developers List <de...@maven.apache.org>
>>> Cc:
>>> Sent: Saturday, December 1, 2012 9:17 AM
>>> Subject: Re: Re-spinning 3.1.0
>>>
>>> Hi Jason,
>>>
>>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>>> sanitize / merge it to propose at least one change for the end user
>>> and demonstrate the interest of the change about logs : a colorized
>>> console.
>>>
>>> I remember you did that in mvnsh/teslashell a long time ago (as an
>>> extension ?) and perhaps it could be easy to add properly this feature
>>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>>
>>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>>> satisfied (it's so good to quickly see highlighted warning and errors
>>> ). I merged it back in the last 3.1.0 tag you did without issue
>>>
>>> Wdyt?
>>>
>>> ---------
>>> Arnaud
>>>
>>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>>
>>>> I'm done with the issues that cropped up so I'm ready to re-spin
>>> 3.1.0.
>>>>
>>>> Anyone want to add anything or discuss anything before I spin this? I'm
>>> not in any rush so if folks want to talk about logging we can. But given the
>>> fact once SLF4J initializes it can't change the implementation plugins
>>> integrating with Maven need to use the implementation we choose. This is how
>>> everything else in the world that integrates SLF4J has to operate so I don't
>>> really see us being any different.
>>>>
>>>> I'll wait until tomorrow to re-spin.
>>>>
>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> 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: Re-spinning 3.1.0
Posted by Gary Gregory <ga...@gmail.com>.
Log4j2 supports color consoles, even on Windows. Is this support
incomplete? I know, I know,still in beta.
Gary
On Dec 1, 2012, at 5:05, Mark Struberg <st...@yahoo.de> wrote:
> sounds great, have Oliviers branch running locally myself without issues.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Arnaud Héritier <ah...@gmail.com>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc:
>> Sent: Saturday, December 1, 2012 9:17 AM
>> Subject: Re: Re-spinning 3.1.0
>>
>> Hi Jason,
>>
>> Couldn't we have a look at olamy's log4j2 branch to see if we could
>> sanitize / merge it to propose at least one change for the end user
>> and demonstrate the interest of the change about logs : a colorized
>> console.
>>
>> I remember you did that in mvnsh/teslashell a long time ago (as an
>> extension ?) and perhaps it could be easy to add properly this feature
>> in 3.1.0 (otherwise it won't be before a 3.2.0).
>>
>> Myself I'm using a 3.1.0 fork with this patch and I' m really
>> satisfied (it's so good to quickly see highlighted warning and errors
>> ). I merged it back in the last 3.1.0 tag you did without issue
>>
>> Wdyt?
>>
>> ---------
>> Arnaud
>>
>> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>>
>>> I'm done with the issues that cropped up so I'm ready to re-spin
>> 3.1.0.
>>>
>>> Anyone want to add anything or discuss anything before I spin this? I'm
>> not in any rush so if folks want to talk about logging we can. But given the
>> fact once SLF4J initializes it can't change the implementation plugins
>> integrating with Maven need to use the implementation we choose. This is how
>> everything else in the world that integrates SLF4J has to operate so I don't
>> really see us being any different.
>>>
>>> I'll wait until tomorrow to re-spin.
>>>
>>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Mark Struberg <st...@yahoo.de>.
sounds great, have Oliviers branch running locally myself without issues.
LieGrue,
strub
----- Original Message -----
> From: Arnaud Héritier <ah...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc:
> Sent: Saturday, December 1, 2012 9:17 AM
> Subject: Re: Re-spinning 3.1.0
>
> Hi Jason,
>
> Couldn't we have a look at olamy's log4j2 branch to see if we could
> sanitize / merge it to propose at least one change for the end user
> and demonstrate the interest of the change about logs : a colorized
> console.
>
> I remember you did that in mvnsh/teslashell a long time ago (as an
> extension ?) and perhaps it could be easy to add properly this feature
> in 3.1.0 (otherwise it won't be before a 3.2.0).
>
> Myself I'm using a 3.1.0 fork with this patch and I' m really
> satisfied (it's so good to quickly see highlighted warning and errors
> ). I merged it back in the last 3.1.0 tag you did without issue
>
> Wdyt?
>
> ---------
> Arnaud
>
> Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
>
>> I'm done with the issues that cropped up so I'm ready to re-spin
> 3.1.0.
>>
>> Anyone want to add anything or discuss anything before I spin this? I'm
> not in any rush so if folks want to talk about logging we can. But given the
> fact once SLF4J initializes it can't change the implementation plugins
> integrating with Maven need to use the implementation we choose. This is how
> everything else in the world that integrates SLF4J has to operate so I don't
> really see us being any different.
>>
>> I'll wait until tomorrow to re-spin.
>>
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re-spinning 3.1.0
Posted by Arnaud Héritier <ah...@gmail.com>.
Hi Jason,
Couldn't we have a look at olamy's log4j2 branch to see if we could
sanitize / merge it to propose at least one change for the end user
and demonstrate the interest of the change about logs : a colorized
console.
I remember you did that in mvnsh/teslashell a long time ago (as an
extension ?) and perhaps it could be easy to add properly this feature
in 3.1.0 (otherwise it won't be before a 3.2.0).
Myself I'm using a 3.1.0 fork with this patch and I' m really
satisfied (it's so good to quickly see highlighted warning and errors
). I merged it back in the last 3.1.0 tag you did without issue
Wdyt?
---------
Arnaud
Le 1 déc. 2012 à 00:20, Jason van Zyl <ja...@tesla.io> a écrit :
> I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0.
>
> Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different.
>
> I'll wait until tomorrow to re-spin.
>
> 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