Logging

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

Hi,

I sorted out the ITs running in embedded mode and here's what I came up with.

I patched SLF4J Simple to work around some static initialization that locked in the log level and the output stream. So the problem in the ITs is not that the output doesn't arrive in the individual files for each IT, but that all the output is going into the file for the first IT. The same sort of problem arises where an IT expects a particular log level based error. The level is locked in for the suite that's run and can't be changed. The patch I made I have to talk to Ceki about as it's not terribly efficient but it works[1].

I also brought the Logback branch up to date and it passes all the ITs. I think I'm at the point where it might make more sense to use a Logback as we're getting into non-simple use cases. I can get Ceki to look at my changes and cut a release if suitablle,  but honestly at this point I propose we integrate Logback.

I will put the branch of the grid tomorrow as I'm not sure what's going on with the CI builds for the ITs as they all seem to be misbehaving.

[1]: https://github.com/jvanzyl/slf4j/commit/aa4b4545f59f84ae9f3122cc0311745ba6b3008e

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

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

I haven't looked at concurrency per se, but I see the IT for the event spy in parallel mode so if that doesn't account for it then it's not something I specifically checked. This is probably where the simple implementation would likely not be adequate.

If you know off hand the ITs that are concurrency specific I'll look at them to make new ones that expand on them.

On Dec 9, 2012, at 5:46 AM, Kristian Rosenvold <kr...@gmail.com> wrote:

> I'm testing the fix now. BY reading code it would seem like this fix
> does eradicate any options for running parallel invocations with
> embedded instances ?
> 
> Kristian
> 
> 
> 2012/12/9 Jason van Zyl <ja...@tesla.io>:
>> Hi,
>> 
>> I sorted out the ITs running in embedded mode and here's what I came up with.
>> 
>> I patched SLF4J Simple to work around some static initialization that locked in the log level and the output stream. So the problem in the ITs is not that the output doesn't arrive in the individual files for each IT, but that all the output is going into the file for the first IT. The same sort of problem arises where an IT expects a particular log level based error. The level is locked in for the suite that's run and can't be changed. The patch I made I have to talk to Ceki about as it's not terribly efficient but it works[1].
>> 
>> I also brought the Logback branch up to date and it passes all the ITs. I think I'm at the point where it might make more sense to use a Logback as we're getting into non-simple use cases. I can get Ceki to look at my changes and cut a release if suitablle,  but honestly at this point I propose we integrate Logback.
>> 
>> I will put the branch of the grid tomorrow as I'm not sure what's going on with the CI builds for the ITs as they all seem to be misbehaving.
>> 
>> [1]: https://github.com/jvanzyl/slf4j/commit/aa4b4545f59f84ae9f3122cc0311745ba6b3008e
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> 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: Logging

[Kristian Rosenvold <kr...@gmail.com>]

I'm testing the fix now. BY reading code it would seem like this fix
does eradicate any options for running parallel invocations with
embedded instances ?

Kristian


2012/12/9 Jason van Zyl <ja...@tesla.io>:
> Hi,
>
> I sorted out the ITs running in embedded mode and here's what I came up with.
>
> I patched SLF4J Simple to work around some static initialization that locked in the log level and the output stream. So the problem in the ITs is not that the output doesn't arrive in the individual files for each IT, but that all the output is going into the file for the first IT. The same sort of problem arises where an IT expects a particular log level based error. The level is locked in for the suite that's run and can't be changed. The patch I made I have to talk to Ceki about as it's not terribly efficient but it works[1].
>
> I also brought the Logback branch up to date and it passes all the ITs. I think I'm at the point where it might make more sense to use a Logback as we're getting into non-simple use cases. I can get Ceki to look at my changes and cut a release if suitablle,  but honestly at this point I propose we integrate Logback.
>
> I will put the branch of the grid tomorrow as I'm not sure what's going on with the CI builds for the ITs as they all seem to be misbehaving.
>
> [1]: https://github.com/jvanzyl/slf4j/commit/aa4b4545f59f84ae9f3122cc0311745ba6b3008e
>
> 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
>
>
>
>
>

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

Re: Logging

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

Color != modern logging API :p...
Le 9 déc. 2012 16:37, "Olivier Lamy" <ol...@apache.org> a écrit :

> It looks others don't want modern stuff.
> So not a problem. During my life I have used ed, vi then vim or emacs
> now an IDE.
> Those last ones make me see "la vie en rose" with some colors.
> BTW I still like vi maybe Keep It So Simple pattern or I'm too old for
> too much modern stuff :-)
>
> Regarding "immature" I think we have previously based our maven core
> on "immature" stuff. If immature means "young libraries build by
> experimented and efficient folks".
>
> But community/consensus/majority decide.
>
> So even if I'm a French guy (those kind of folks who usually grumble a
> lot :-) ), I will stop complaining (at least I can configure my local
> installation with my preferred mode).
>
> Cheers
> --
> Olivier
>
>
> 2012/12/9 Romain Manni-Bucau <rm...@gmail.com>:
> > Hi guys,
> >
> > Simple, log4j, logback...nobody cares about jdk? It is far better than
> > simple and enough by default avoiding log4j/logback issue...then the
> > question would rather be why slf4j since JUL is enough and can be the API
> > as in cxf, owb etc...
> > Le 9 déc. 2012 16:18, "Jason van Zyl" <ja...@tesla.io> a écrit :
> >
> >> I agree. I don't believe it's reasonable path to pick an immature
> library
> >> for the core given the existence of Logback.
> >>
> >> Arnaud, I believe you felt the same way?
> >>
> >> I honestly gave SLF4J Simple a good run and pushed it with Ceki to make
> it
> >> do more than originally intended but I don't think it makes sense to
> push
> >> anymore.
> >>
> >> If other committers have an opinion let's please get this sorted out.
> >>
> >> On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold <
> >> kristian.rosenvold@gmail.com> wrote:
> >>
> >> > 2012/12/9 Olivier Lamy <ol...@apache.org>:
> >> >> Perso I'm fine using log4j2.
> >> >> I use the branch I pushed for some weeks now and I'm happy.
> >> >> Log4j2 has quickly added a feature I needed and release it.
> >> >> Furthermore I'm fine working with an Apache community in case of any
> >> >> issue we could have.
> >> >
> >> > I'm not entirely sure I follow where this discussion is actually
> >> > going,  but I'm firmly opposed
> >> > to including a brand new logging framework as default in m3.
> >> >
> >> > Kristian
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> Our achievements speak for themselves. What we have to keep track
> >> of are our failures, discouragements and doubts. We tend to forget
> >> the past difficulties, the many false starts, and the painful
> >> groping. We see our past achievements as the end result of a
> >> clean forward thrust, and our present difficulties as
> >> signs of decline and decay.
> >>
> >>  -- Eric Hoffer, Reflections on the Human Condition
> >>
> >>
> >>
> >>
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Logging

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

On Dec 9, 2012, at 10:37 AM, Olivier Lamy <ol...@apache.org> wrote:

> It looks others don't want modern stuff.
> So not a problem. During my life I have used ed, vi then vim or emacs
> now an IDE.
> Those last ones make me see "la vie en rose" with some colors.
> BTW I still like vi maybe Keep It So Simple pattern or I'm too old for
> too much modern stuff :-)

We can do the coloured logging with Logback, I don't see a problem there. I commented that option out in the Logback branch and we can probably make it easier with something in settings.xml but I don't think we're limited feature-wise by selecting Logback.

> 
> Regarding "immature" I think we have previously based our maven core
> on "immature" stuff. If immature means "young libraries build by
> experimented and efficient folks".

Where an option didn't exist sure. 

Plexus and Spring were started at almost the exact same time, and while there was Avalon and Pico they were all being actively developed and it was easier for me to make something specific for Maven where there were many injection sites, I wanted to disallow cycles in the components, wanted to use annotations to drive the generation of the metadata, and it needed to be embeddable. The Avalon Phoenix container was the best fit but the whole Avalon project went down in flames at Apache. The author of that container, which is probably still one of the best DI implementations that exists, was the only committer ever to be ejected from Apache so I just chose not to use that because I felt that whole episode was a travesty. But I tried them all, and though I probably could have tried harder to use one of the other projects there was no mature option.

As for Modello there was EMF which was also immature and I tried to swap out Modello to use EMF recently and I don't think it's possible even now. The other option was XMI but the model for Maven was 5mb and the tooling was horrendously complicated. But Modello used parts of Castor and things that did exist. Again there wasn't really a mature option 8 years ago for simple generation. Again I could have looked harder and my appetite for reimplementation was certainly more powerful several years ago but I don't think there was really another option.

For Sisu it is the same situation. We used Guice as the base as it was clearly the best fit, mature and battle tested, embeddable and an SPI flexible enough to build upon. What we needed to make Guice work for Maven simply doesn't exist. What Stuart created still doesn't really have any counterparts and certainly no mature options. What Stuart created is simply an amazing piece of technology. I don't think anyone can really appreciate what it took to get Maven to run on stock Guice. This was all to eliminate a silo of technology, Plexus, that really puts the project at risk. So while I may have written things in the past where there were no options I have tried to eliminate them as time has passed and this was not an inexpensive endeavor.

Logback is distinctly different in that there is a mature option that has been readily absorbed by many projects including many at Apache. Logback has the features we need and I think it's the most sensible choice. If it doesn't have things we need I will gladly help implement them.

I'll stop beating the dead horse but I just wanted to point out that I think this selection of a logging framework is distinctly different then our previous major technology choices.

> 
> But community/consensus/majority decide.
> 
> So even if I'm a French guy (those kind of folks who usually grumble a
> lot :-) ), I will stop complaining (at least I can configure my local
> installation with my preferred mode).
> 
> Cheers
> --
> Olivier
> 
> 
> 2012/12/9 Romain Manni-Bucau <rm...@gmail.com>:
>> Hi guys,
>> 
>> Simple, log4j, logback...nobody cares about jdk? It is far better than
>> simple and enough by default avoiding log4j/logback issue...then the
>> question would rather be why slf4j since JUL is enough and can be the API
>> as in cxf, owb etc...
>> Le 9 déc. 2012 16:18, "Jason van Zyl" <ja...@tesla.io> a écrit :
>> 
>>> I agree. I don't believe it's reasonable path to pick an immature library
>>> for the core given the existence of Logback.
>>> 
>>> Arnaud, I believe you felt the same way?
>>> 
>>> I honestly gave SLF4J Simple a good run and pushed it with Ceki to make it
>>> do more than originally intended but I don't think it makes sense to push
>>> anymore.
>>> 
>>> If other committers have an opinion let's please get this sorted out.
>>> 
>>> On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold <
>>> kristian.rosenvold@gmail.com> wrote:
>>> 
>>>> 2012/12/9 Olivier Lamy <ol...@apache.org>:
>>>>> Perso I'm fine using log4j2.
>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>> issue we could have.
>>>> 
>>>> I'm not entirely sure I follow where this discussion is actually
>>>> going,  but I'm firmly opposed
>>>> to including a brand new logging framework as default in m3.
>>>> 
>>>> Kristian
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>> 
>>> Our achievements speak for themselves. What we have to keep track
>>> of are our failures, discouragements and doubts. We tend to forget
>>> the past difficulties, the many false starts, and the painful
>>> groping. We see our past achievements as the end result of a
>>> clean forward thrust, and our present difficulties as
>>> signs of decline and decay.
>>> 
>>> -- Eric Hoffer, Reflections on the Human Condition
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> ---------------------------------------------------------------------
> 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: Logging

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

It looks others don't want modern stuff.
So not a problem. During my life I have used ed, vi then vim or emacs
now an IDE.
Those last ones make me see "la vie en rose" with some colors.
BTW I still like vi maybe Keep It So Simple pattern or I'm too old for
too much modern stuff :-)

Regarding "immature" I think we have previously based our maven core
on "immature" stuff. If immature means "young libraries build by
experimented and efficient folks".

But community/consensus/majority decide.

So even if I'm a French guy (those kind of folks who usually grumble a
lot :-) ), I will stop complaining (at least I can configure my local
installation with my preferred mode).

Cheers
--
Olivier


2012/12/9 Romain Manni-Bucau <rm...@gmail.com>:
> Hi guys,
>
> Simple, log4j, logback...nobody cares about jdk? It is far better than
> simple and enough by default avoiding log4j/logback issue...then the
> question would rather be why slf4j since JUL is enough and can be the API
> as in cxf, owb etc...
> Le 9 déc. 2012 16:18, "Jason van Zyl" <ja...@tesla.io> a écrit :
>
>> I agree. I don't believe it's reasonable path to pick an immature library
>> for the core given the existence of Logback.
>>
>> Arnaud, I believe you felt the same way?
>>
>> I honestly gave SLF4J Simple a good run and pushed it with Ceki to make it
>> do more than originally intended but I don't think it makes sense to push
>> anymore.
>>
>> If other committers have an opinion let's please get this sorted out.
>>
>> On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold <
>> kristian.rosenvold@gmail.com> wrote:
>>
>> > 2012/12/9 Olivier Lamy <ol...@apache.org>:
>> >> Perso I'm fine using log4j2.
>> >> I use the branch I pushed for some weeks now and I'm happy.
>> >> Log4j2 has quickly added a feature I needed and release it.
>> >> Furthermore I'm fine working with an Apache community in case of any
>> >> issue we could have.
>> >
>> > I'm not entirely sure I follow where this discussion is actually
>> > going,  but I'm firmly opposed
>> > to including a brand new logging framework as default in m3.
>> >
>> > Kristian
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> Our achievements speak for themselves. What we have to keep track
>> of are our failures, discouragements and doubts. We tend to forget
>> the past difficulties, the many false starts, and the painful
>> groping. We see our past achievements as the end result of a
>> clean forward thrust, and our present difficulties as
>> signs of decline and decay.
>>
>>  -- Eric Hoffer, Reflections on the Human Condition
>>
>>
>>
>>
>>
>>

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

Re: Logging

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

Hi guys,

Simple, log4j, logback...nobody cares about jdk? It is far better than
simple and enough by default avoiding log4j/logback issue...then the
question would rather be why slf4j since JUL is enough and can be the API
as in cxf, owb etc...
Le 9 déc. 2012 16:18, "Jason van Zyl" <ja...@tesla.io> a écrit :

> I agree. I don't believe it's reasonable path to pick an immature library
> for the core given the existence of Logback.
>
> Arnaud, I believe you felt the same way?
>
> I honestly gave SLF4J Simple a good run and pushed it with Ceki to make it
> do more than originally intended but I don't think it makes sense to push
> anymore.
>
> If other committers have an opinion let's please get this sorted out.
>
> On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
> > 2012/12/9 Olivier Lamy <ol...@apache.org>:
> >> Perso I'm fine using log4j2.
> >> I use the branch I pushed for some weeks now and I'm happy.
> >> Log4j2 has quickly added a feature I needed and release it.
> >> Furthermore I'm fine working with an Apache community in case of any
> >> issue we could have.
> >
> > I'm not entirely sure I follow where this discussion is actually
> > going,  but I'm firmly opposed
> > to including a brand new logging framework as default in m3.
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
>  -- Eric Hoffer, Reflections on the Human Condition
>
>
>
>
>
>

Re: Logging

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

I agree. I don't believe it's reasonable path to pick an immature library for the core given the existence of Logback. 

Arnaud, I believe you felt the same way?

I honestly gave SLF4J Simple a good run and pushed it with Ceki to make it do more than originally intended but I don't think it makes sense to push anymore. 

If other committers have an opinion let's please get this sorted out. 

On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold <kr...@gmail.com> wrote:

> 2012/12/9 Olivier Lamy <ol...@apache.org>:
>> Perso I'm fine using log4j2.
>> I use the branch I pushed for some weeks now and I'm happy.
>> Log4j2 has quickly added a feature I needed and release it.
>> Furthermore I'm fine working with an Apache community in case of any
>> issue we could have.
> 
> I'm not entirely sure I follow where this discussion is actually
> going,  but I'm firmly opposed
> to including a brand new logging framework as default in m3.
> 
> Kristian
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

 -- Eric Hoffer, Reflections on the Human Condition

Re: Logging

[Mark Struberg <st...@yahoo.de>]

sorry, you are right, should have been slf4j-simple, etc.




----- Original Message -----
> From: Anders Hammar <an...@hammar.net>
> To: Maven Developers List <de...@maven.apache.org>
> Cc: 
> Sent: Monday, December 10, 2012 11:20 AM
> Subject: Re: Logging
> 
>>  Another thing to remember is that logback is a LocationAwareLogger afaik
>>  (log4j-simple is not!) thus it suffers from the API compat problem.
>>  By exposing it in the maven core class realm we might trash all projects
>>  with slf4j < 1.6. This even got acknowledged by Ceki...
>>  This was the reason why we initially picked slf4j-simple in the first
>>  place.
>> 
>>  Hervés work is a mechanism to solve the problem in the plugins. But what
>>  about _projects_ using log4j-1.5 or lower? There is no simple 'fix your
>>  pom' answer. We would force those users to upgrade their projects. 3
>>  possible solutions: we force them to update or do we auto-detect such
>>  dependencies and then _not_ expose slf4j in our core realm? I spare you the
>>  obvious 3rd option...
>> 
> 
> You're confusing me! I believe you use "log4j" in two places above 
> where it
> should be "slf4j", right?
> 
> Also, you're bringing in the perspective of "projects" which I 
> take it
> you're talking about the Maven projects being built. Correct? I've been
> assuming that the logging framework (slf4j) and the impl (whichever one)
> does NOT affect the Maven project being built, but only possibly the
> plugins executed. Isn't that correct? If so your point is not valid at all.
> The compat problem you're talking about I recall Ceki explained was
> extremely minor (in that sense that not very often used) and not likely to
> affect any plugin but only the ones doing advanced logging (and using an
> older slf4j version). Someone with better knowledge in this very specific
> topic should probably straighten this out; it's outside of my expertise.
> 
> As this compat problem has popped up during the discussion, do you have an
> example of a real world case? That would be good so that we just don't have
> a brain ghost here.
> 
> /Anders
> 
> 
> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>  > From: Olivier Lamy <ol...@apache.org>
>>  > To: Maven Developers List <de...@maven.apache.org>
>>  > Cc:
>>  > Sent: Monday, December 10, 2012 9:25 AM
>>  > Subject: Re: Logging
>>  >
>>  > 2012/12/10 Hervé BOUTEMY <he...@free.fr>:
>>  >>  Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>>  >>>  I think it's time to stop patching SLF4J Simple. I have 
> an
>>  > inefficient fix
>>  >>>  for the embedding problem, but we're likely to run into 
> issues
>>  > concurrency
>>  >>>  with parallel builds and who knows what else. This will 
> patch/change
>>  #5
>>  > and
>>  >>>  many hours of trying to get SLF4J Simple to work but I think 
> we're
>>  > pushing
>>  >>>  the simple implementation beyond its scope. So I'd just 
> like to put
>>  > in
>>  >>>  Logback and be done with it.
>>  >>>
>>  >>>  There are at least three of us opposed to using a new logging
>>  > framework,
>>  >>  logging *implementation*, please, not framework: the framework is
>>  > slf4j-api,
>>  >>  on which our code will have much dependency. The logging
>>  implementation is
>>  > far
>>  >>  less invasive choice (even if not completely null).
>>  >>
>>  >>>  but I don't think there is anyone against using Logback.
>>  >>  why this provocation? (should I say lack of respect for others
>>  opinion?)
>>  >>
>>  >>>  I honestly don't think
>>  >>>  there is any rational argument for not using Logback,  so 
> after doing
>>  > all
>>  >>>  the SLF4J work and making a best effort to use SLF4J Simple I 
> think
>>  > it's
>>  >>>  pointless to pursue that path any longer and put in Logback.
>>  >>  we'll need to wait for 3.1.1 and a vote to have a chance to 
> stop
>>  > tension about
>>  >>  this: whatever choice is done, there will be some devs unhappy 
> who will
>>  > have
>>  >>  to live with it
>>  >>
>>  >>  notice I won't be able to reply for the next half day, my 
> intent with
>>  > this
>>  >>  reply is just to avoid one more re-spin of a feeling that the 
> vote
>>  > won't
>>  >>  happen and let Olivier once more jump on the case
>>  >>  I just hope I won't have to read a lot of replies to this 
> tonight when
>>  > I'm
>>  >>  back from work and loose my time carefully reading if anything 
> new or
>>  >>  interesting is written
>>  >>
>>  >
>>  > I have already explained my opinion.
>>  > Folks think log4j2 is "immature" and/or don't have a 
> community of
>>  > various people.
>>  >
>>  > Furthermore it looks it's not anymore possible to use 
> "immature"
>>  > libraries in core (whereas it has been done for more important part:
>>  > sisu or aether).
>>  >
>>  > But now that's not anymore possible...
>>  > Well things evolve and POV can change that's the life....
>>  >
>>  > BTW due to our policy [1] and if I correctly read license here [2] a
>>  > vote is mandatory. (and don't ask me to start this vote :-) ).
>>  >
>>  > Cheers
>>  > --
>>  > Olivier
>>  > [1] http://maven.apache.org/developers/dependency-policies
>>  > [2] http://logback.qos.ch/license.html
>>  >
>>  >>  Regards,
>>  >>
>>  >>  Hervé
>>  >>
>>  >>>  On Dec 9, 2012, at 5:45 PM, Arnaud Héritier 
> <ah...@gmail.com>
>>  > wrote:
>>  >>>  > I'm a little bit lost too.
>>  >>>  > Thus for now in 3.1.0 we didn't want to provide a 
> new logging
>>  > impl fwk
>>  >>>  > (for
>>  >>>  > many - good - reasons) but the last bug discovered by 
> Kristian can
>>  > be
>>  >>>  > solved only
>>  >>>  > * by having a fix from slf4j (but it isn't sure that 
> the patch
>>  > makes sense
>>  >>>  > - to be validated by Ceki)
>>  >>>  > * or by using a more evolved impl like logback (or log4j 
> ...).
>>  >>>  > I think that everyone's will prefer the first 
> solution if
>>  > possible but if
>>  >>>  > we cannot we'll have the question to select the 
> impl.
>>  >>>  > Do we need to vote ? Is there really a question logback 
> vs
>>  > log4j(2) ?
>>  >>>  > Like I said in another thread I'll understand if the 
> project
>>  > decide to
>>  >>>  > choose log4j2 even if it is young because we want to 
> support
>>  > another ASF
>>  >>>  > initiative (And I'm sure we won't have to regret 
> it, and
>>  > we'll have a
>>  >>>  > really good support from its team) but in a general case 
> I would
>>  > prefer to
>>  >>>  > choose logback which is today the reference logging 
> framework (I
>>  > that case
>>  >>>  > we need to have a PMC vote to accept an external 
> component under
>>  > EPL
>>  >>>  > license 
> http://maven.apache.org/developers/dependency-policies ?).
>>  >>>  >
>>  >>>  > What do we need (for 3.1.0) ? What do we do ?
>>  >>>  >
>>  >>>  > Arnaud
>>  >>>  >
>>  >>>  > On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar
>>  > <an...@hammar.net> wrote:
>>  >>>  >> Not sure where to get into this thread, but I'd 
> just like
>>  > to add my
>>  >>>  >> perspective on this topic.
>>  >>>  >>
>>  >>>  >> For this first release I would prefer it to not 
> include any of
>>  > the more
>>  >>>  >> advanced slf4j implementations, like a few others 
> have already
>>  > also
>>  >>>  >> stated.
>>  >>>  >> Using simple would give us a good start on this new 
> path while
>>  > we
>>  >>>  >> investigate what we and the community want feature 
> wise and
>>  > then select
>>  >>>  >> an
>>  >>>  >> implementation based on these requirements. However, 
> if
>>  > slf4-simple can't
>>  >>>  >> do the job of the old behavior when we might not 
> have that
>>  > option
>>  >>>  >> unfortunately. Or, possibly we could live with these
>>  > deficiencies? I'll
>>  >>>  >> leave that to others working with that to decide.
>>  >>>  >>
>>  >>>  >> But if we have to decide on a more advanced 
> implementation my
>>  > choice
>>  >>>  >> would
>>  >>>  >> be logback. My choice is based on two things where 
> one being a
>>  > past
>>  >>>  >> experience where I developed an audit logging 
> solution based
>>  > on logback,
>>  >>>  >> where my research showed that log4j had so many 
> deficiencies
>>  > when it came
>>  >>>  >> to more advanced cases. log4j2 might be a different 
> story with
>>  > this fixed
>>  >>>  >> though, but I don't see any reason trying 
> something else
>>  > when there is
>>  >>>  >> proven option. Secondly, I have good confidence in 
> Ceki and
>>  > that he will
>>  >>>  >> help us out should we need that. I'm not saying 
> those
>>  > working with log4j2
>>  >>>  >> will not, it's just that I don't know their 
> track
>>  > record as I know
>>  >>>  >> Ceki's.
>>  >>>  >>
>>  >>>  >> But to repeat myself, going simple in the first 
> release would
>>  > be so much
>>  >>>  >> better. Then we could get our requirements after 
> this first
>>  > release and
>>  >>>  >> do
>>  >>>  >> a selection based on them rather than just a gut 
> feeling.
>>  > Although using
>>  >>>  >> slf4j as the API gives us the technical possibility 
> of
>>  > switching impl
>>  >>>  >> later
>>  >>>  >> on, I don't think we want that as we can 
> probably expect
>>  > some people do
>>  >>>  >> solutions expecting a specific impl (as we've 
> seen in the
>>  > Sonar plugin
>>  >>>  >> for
>>  >>>  >> example).
>>  >>>  >>
>>  >>>  >> /Anders
>>  >>>  >>
>>  >>>  >>
>>  >>>  >> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly 
> <
>>  >>>  >>
>>  >>>  >> stephen.alan.connolly@gmail.com> wrote:
>>  >>>  >>> On Sunday, 9 December 2012, Kristian Rosenvold 
> wrote:
>>  >>>  >>>> 2012/12/9 Olivier Lamy <olamy@apache.org
>>  > <javascript:;>>:
>>  >>>  >>>>> Perso I'm fine using log4j2.
>>  >>>  >>>>> I use the branch I pushed for some weeks 
> now and
>>  > I'm happy.
>>  >>>  >>>>> Log4j2 has quickly added a feature I 
> needed and
>>  > release it.
>>  >>>  >>>>> Furthermore I'm fine working with an 
> Apache
>>  > community in case of any
>>  >>>  >>>>> issue we could have.
>>  >>>  >>>>
>>  >>>  >>>> I'm not entirely sure I follow where 
> this
>>  > discussion is actually
>>  >>>  >>>> going,  but I'm firmly opposed
>>  >>>  >>>> to including a brand new logging framework 
> as default
>>  > in m3.
>>  >>>  >>>
>>  >>>  >>> +1
>>  >>>  >>>
>>  >>>  >>>> Kristian
>>  >>>  >>>>
>>  >>>  >>>>
>>  > ---------------------------------------------------------------------
>>  >>>  >>>> To unsubscribe, e-mail:
>>  > dev-unsubscribe@maven.apache.org<javascript:;>
>>  >>>  >>>> For additional commands, e-mail:
>>  > dev-help@maven.apache.org
>>  >>>  >>
>>  >>>  >> <javascript:;>
>>  >>>
>>  >>>  Thanks,
>>  >>>
>>  >>>  Jason
>>  >>>
>>  >>>  ----------------------------------------------------------
>>  >>>  Jason van Zyl
>>  >>>  Founder & CTO, Sonatype
>>  >>>  Founder,  Apache Maven
>>  >>>  http://twitter.com/jvanzyl
>>  >>>  ---------------------------------------------------------
>>  >>>
>>  >>>  Three people can keep a secret provided two of them are dead.
>>  >>>
>>  >>>   -- Benjamin Franklin
>>  >>
>>  >>  
> ---------------------------------------------------------------------
>>  >>  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
>> 
>> 
> 

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

Re: Logging

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

> Another thing to remember is that logback is a LocationAwareLogger afaik
> (log4j-simple is not!) thus it suffers from the API compat problem.
> By exposing it in the maven core class realm we might trash all projects
> with slf4j < 1.6. This even got acknowledged by Ceki...
> This was the reason why we initially picked slf4j-simple in the first
> place.
>
> Hervés work is a mechanism to solve the problem in the plugins. But what
> about _projects_ using log4j-1.5 or lower? There is no simple 'fix your
> pom' answer. We would force those users to upgrade their projects. 3
> possible solutions: we force them to update or do we auto-detect such
> dependencies and then _not_ expose slf4j in our core realm? I spare you the
> obvious 3rd option...
>

You're confusing me! I believe you use "log4j" in two places above where it
should be "slf4j", right?

Also, you're bringing in the perspective of "projects" which I take it
you're talking about the Maven projects being built. Correct? I've been
assuming that the logging framework (slf4j) and the impl (whichever one)
does NOT affect the Maven project being built, but only possibly the
plugins executed. Isn't that correct? If so your point is not valid at all.
The compat problem you're talking about I recall Ceki explained was
extremely minor (in that sense that not very often used) and not likely to
affect any plugin but only the ones doing advanced logging (and using an
older slf4j version). Someone with better knowledge in this very specific
topic should probably straighten this out; it's outside of my expertise.

As this compat problem has popped up during the discussion, do you have an
example of a real world case? That would be good so that we just don't have
a brain ghost here.

/Anders



>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Olivier Lamy <ol...@apache.org>
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc:
> > Sent: Monday, December 10, 2012 9:25 AM
> > Subject: Re: Logging
> >
> > 2012/12/10 Hervé BOUTEMY <he...@free.fr>:
> >>  Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
> >>>  I think it's time to stop patching SLF4J Simple. I have an
> > inefficient fix
> >>>  for the embedding problem, but we're likely to run into issues
> > concurrency
> >>>  with parallel builds and who knows what else. This will patch/change
> #5
> > and
> >>>  many hours of trying to get SLF4J Simple to work but I think we're
> > pushing
> >>>  the simple implementation beyond its scope. So I'd just like to put
> > in
> >>>  Logback and be done with it.
> >>>
> >>>  There are at least three of us opposed to using a new logging
> > framework,
> >>  logging *implementation*, please, not framework: the framework is
> > slf4j-api,
> >>  on which our code will have much dependency. The logging
> implementation is
> > far
> >>  less invasive choice (even if not completely null).
> >>
> >>>  but I don't think there is anyone against using Logback.
> >>  why this provocation? (should I say lack of respect for others
> opinion?)
> >>
> >>>  I honestly don't think
> >>>  there is any rational argument for not using Logback,  so after doing
> > all
> >>>  the SLF4J work and making a best effort to use SLF4J Simple I think
> > it's
> >>>  pointless to pursue that path any longer and put in Logback.
> >>  we'll need to wait for 3.1.1 and a vote to have a chance to stop
> > tension about
> >>  this: whatever choice is done, there will be some devs unhappy who will
> > have
> >>  to live with it
> >>
> >>  notice I won't be able to reply for the next half day, my intent with
> > this
> >>  reply is just to avoid one more re-spin of a feeling that the vote
> > won't
> >>  happen and let Olivier once more jump on the case
> >>  I just hope I won't have to read a lot of replies to this tonight when
> > I'm
> >>  back from work and loose my time carefully reading if anything new or
> >>  interesting is written
> >>
> >
> > I have already explained my opinion.
> > Folks think log4j2 is "immature" and/or don't have a community of
> > various people.
> >
> > Furthermore it looks it's not anymore possible to use "immature"
> > libraries in core (whereas it has been done for more important part:
> > sisu or aether).
> >
> > But now that's not anymore possible...
> > Well things evolve and POV can change that's the life....
> >
> > BTW due to our policy [1] and if I correctly read license here [2] a
> > vote is mandatory. (and don't ask me to start this vote :-) ).
> >
> > Cheers
> > --
> > Olivier
> > [1] http://maven.apache.org/developers/dependency-policies
> > [2] http://logback.qos.ch/license.html
> >
> >>  Regards,
> >>
> >>  Hervé
> >>
> >>>  On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com>
> > wrote:
> >>>  > I'm a little bit lost too.
> >>>  > Thus for now in 3.1.0 we didn't want to provide a new logging
> > impl fwk
> >>>  > (for
> >>>  > many - good - reasons) but the last bug discovered by Kristian can
> > be
> >>>  > solved only
> >>>  > * by having a fix from slf4j (but it isn't sure that the patch
> > makes sense
> >>>  > - to be validated by Ceki)
> >>>  > * or by using a more evolved impl like logback (or log4j ...).
> >>>  > I think that everyone's will prefer the first solution if
> > possible but if
> >>>  > we cannot we'll have the question to select the impl.
> >>>  > Do we need to vote ? Is there really a question logback vs
> > log4j(2) ?
> >>>  > Like I said in another thread I'll understand if the project
> > decide to
> >>>  > choose log4j2 even if it is young because we want to support
> > another ASF
> >>>  > initiative (And I'm sure we won't have to regret it, and
> > we'll have a
> >>>  > really good support from its team) but in a general case I would
> > prefer to
> >>>  > choose logback which is today the reference logging framework (I
> > that case
> >>>  > we need to have a PMC vote to accept an external component under
> > EPL
> >>>  > license http://maven.apache.org/developers/dependency-policies ?).
> >>>  >
> >>>  > What do we need (for 3.1.0) ? What do we do ?
> >>>  >
> >>>  > Arnaud
> >>>  >
> >>>  > On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar
> > <an...@hammar.net> wrote:
> >>>  >> Not sure where to get into this thread, but I'd just like
> > to add my
> >>>  >> perspective on this topic.
> >>>  >>
> >>>  >> For this first release I would prefer it to not include any of
> > the more
> >>>  >> advanced slf4j implementations, like a few others have already
> > also
> >>>  >> stated.
> >>>  >> Using simple would give us a good start on this new path while
> > we
> >>>  >> investigate what we and the community want feature wise and
> > then select
> >>>  >> an
> >>>  >> implementation based on these requirements. However, if
> > slf4-simple can't
> >>>  >> do the job of the old behavior when we might not have that
> > option
> >>>  >> unfortunately. Or, possibly we could live with these
> > deficiencies? I'll
> >>>  >> leave that to others working with that to decide.
> >>>  >>
> >>>  >> But if we have to decide on a more advanced implementation my
> > choice
> >>>  >> would
> >>>  >> be logback. My choice is based on two things where one being a
> > past
> >>>  >> experience where I developed an audit logging solution based
> > on logback,
> >>>  >> where my research showed that log4j had so many deficiencies
> > when it came
> >>>  >> to more advanced cases. log4j2 might be a different story with
> > this fixed
> >>>  >> though, but I don't see any reason trying something else
> > when there is
> >>>  >> proven option. Secondly, I have good confidence in Ceki and
> > that he will
> >>>  >> help us out should we need that. I'm not saying those
> > working with log4j2
> >>>  >> will not, it's just that I don't know their track
> > record as I know
> >>>  >> Ceki's.
> >>>  >>
> >>>  >> But to repeat myself, going simple in the first release would
> > be so much
> >>>  >> better. Then we could get our requirements after this first
> > release and
> >>>  >> do
> >>>  >> a selection based on them rather than just a gut feeling.
> > Although using
> >>>  >> slf4j as the API gives us the technical possibility of
> > switching impl
> >>>  >> later
> >>>  >> on, I don't think we want that as we can probably expect
> > some people do
> >>>  >> solutions expecting a specific impl (as we've seen in the
> > Sonar plugin
> >>>  >> for
> >>>  >> example).
> >>>  >>
> >>>  >> /Anders
> >>>  >>
> >>>  >>
> >>>  >> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
> >>>  >>
> >>>  >> stephen.alan.connolly@gmail.com> wrote:
> >>>  >>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
> >>>  >>>> 2012/12/9 Olivier Lamy <olamy@apache.org
> > <javascript:;>>:
> >>>  >>>>> Perso I'm fine using log4j2.
> >>>  >>>>> I use the branch I pushed for some weeks now and
> > I'm happy.
> >>>  >>>>> Log4j2 has quickly added a feature I needed and
> > release it.
> >>>  >>>>> Furthermore I'm fine working with an Apache
> > community in case of any
> >>>  >>>>> issue we could have.
> >>>  >>>>
> >>>  >>>> I'm not entirely sure I follow where this
> > discussion is actually
> >>>  >>>> going,  but I'm firmly opposed
> >>>  >>>> to including a brand new logging framework as default
> > in m3.
> >>>  >>>
> >>>  >>> +1
> >>>  >>>
> >>>  >>>> Kristian
> >>>  >>>>
> >>>  >>>>
> > ---------------------------------------------------------------------
> >>>  >>>> To unsubscribe, e-mail:
> > dev-unsubscribe@maven.apache.org<javascript:;>
> >>>  >>>> For additional commands, e-mail:
> > dev-help@maven.apache.org
> >>>  >>
> >>>  >> <javascript:;>
> >>>
> >>>  Thanks,
> >>>
> >>>  Jason
> >>>
> >>>  ----------------------------------------------------------
> >>>  Jason van Zyl
> >>>  Founder & CTO, Sonatype
> >>>  Founder,  Apache Maven
> >>>  http://twitter.com/jvanzyl
> >>>  ---------------------------------------------------------
> >>>
> >>>  Three people can keep a secret provided two of them are dead.
> >>>
> >>>   -- Benjamin Franklin
> >>
> >>  ---------------------------------------------------------------------
> >>  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: Logging

[Mark Struberg <st...@yahoo.de>]

Another thing to remember is that logback is a LocationAwareLogger afaik (log4j-simple is not!) thus it suffers from the API compat problem.
By exposing it in the maven core class realm we might trash all projects with slf4j < 1.6. This even got acknowledged by Ceki...
This was the reason why we initially picked slf4j-simple in the first place.

Hervés work is a mechanism to solve the problem in the plugins. But what about _projects_ using log4j-1.5 or lower? There is no simple 'fix your pom' answer. We would force those users to upgrade their projects. 3 possible solutions: we force them to update or do we auto-detect such dependencies and then _not_ expose slf4j in our core realm? I spare you the obvious 3rd option...

LieGrue,
strub




----- Original Message -----
> From: Olivier Lamy <ol...@apache.org>
> To: Maven Developers List <de...@maven.apache.org>
> Cc: 
> Sent: Monday, December 10, 2012 9:25 AM
> Subject: Re: Logging
> 
> 2012/12/10 Hervé BOUTEMY <he...@free.fr>:
>>  Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>>>  I think it's time to stop patching SLF4J Simple. I have an 
> inefficient fix
>>>  for the embedding problem, but we're likely to run into issues 
> concurrency
>>>  with parallel builds and who knows what else. This will patch/change #5 
> and
>>>  many hours of trying to get SLF4J Simple to work but I think we're 
> pushing
>>>  the simple implementation beyond its scope. So I'd just like to put 
> in
>>>  Logback and be done with it.
>>> 
>>>  There are at least three of us opposed to using a new logging 
> framework,
>>  logging *implementation*, please, not framework: the framework is 
> slf4j-api,
>>  on which our code will have much dependency. The logging implementation is 
> far
>>  less invasive choice (even if not completely null).
>> 
>>>  but I don't think there is anyone against using Logback.
>>  why this provocation? (should I say lack of respect for others opinion?)
>> 
>>>  I honestly don't think
>>>  there is any rational argument for not using Logback,  so after doing 
> all
>>>  the SLF4J work and making a best effort to use SLF4J Simple I think 
> it's
>>>  pointless to pursue that path any longer and put in Logback.
>>  we'll need to wait for 3.1.1 and a vote to have a chance to stop 
> tension about
>>  this: whatever choice is done, there will be some devs unhappy who will 
> have
>>  to live with it
>> 
>>  notice I won't be able to reply for the next half day, my intent with 
> this
>>  reply is just to avoid one more re-spin of a feeling that the vote 
> won't
>>  happen and let Olivier once more jump on the case
>>  I just hope I won't have to read a lot of replies to this tonight when 
> I'm
>>  back from work and loose my time carefully reading if anything new or
>>  interesting is written
>> 
> 
> I have already explained my opinion.
> Folks think log4j2 is "immature" and/or don't have a community of
> various people.
> 
> Furthermore it looks it's not anymore possible to use "immature"
> libraries in core (whereas it has been done for more important part:
> sisu or aether).
> 
> But now that's not anymore possible...
> Well things evolve and POV can change that's the life....
> 
> BTW due to our policy [1] and if I correctly read license here [2] a
> vote is mandatory. (and don't ask me to start this vote :-) ).
> 
> Cheers
> --
> Olivier
> [1] http://maven.apache.org/developers/dependency-policies
> [2] http://logback.qos.ch/license.html
> 
>>  Regards,
>> 
>>  Hervé
>> 
>>>  On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> 
> wrote:
>>>  > I'm a little bit lost too.
>>>  > Thus for now in 3.1.0 we didn't want to provide a new logging 
> impl fwk
>>>  > (for
>>>  > many - good - reasons) but the last bug discovered by Kristian can 
> be
>>>  > solved only
>>>  > * by having a fix from slf4j (but it isn't sure that the patch 
> makes sense
>>>  > - to be validated by Ceki)
>>>  > * or by using a more evolved impl like logback (or log4j ...).
>>>  > I think that everyone's will prefer the first solution if 
> possible but if
>>>  > we cannot we'll have the question to select the impl.
>>>  > Do we need to vote ? Is there really a question logback vs 
> log4j(2) ?
>>>  > Like I said in another thread I'll understand if the project 
> decide to
>>>  > choose log4j2 even if it is young because we want to support 
> another ASF
>>>  > initiative (And I'm sure we won't have to regret it, and 
> we'll have a
>>>  > really good support from its team) but in a general case I would 
> prefer to
>>>  > choose logback which is today the reference logging framework (I 
> that case
>>>  > we need to have a PMC vote to accept an external component under 
> EPL
>>>  > license http://maven.apache.org/developers/dependency-policies ?).
>>>  >
>>>  > What do we need (for 3.1.0) ? What do we do ?
>>>  >
>>>  > Arnaud
>>>  >
>>>  > On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar 
> <an...@hammar.net> wrote:
>>>  >> Not sure where to get into this thread, but I'd just like 
> to add my
>>>  >> perspective on this topic.
>>>  >>
>>>  >> For this first release I would prefer it to not include any of 
> the more
>>>  >> advanced slf4j implementations, like a few others have already 
> also
>>>  >> stated.
>>>  >> Using simple would give us a good start on this new path while 
> we
>>>  >> investigate what we and the community want feature wise and 
> then select
>>>  >> an
>>>  >> implementation based on these requirements. However, if 
> slf4-simple can't
>>>  >> do the job of the old behavior when we might not have that 
> option
>>>  >> unfortunately. Or, possibly we could live with these 
> deficiencies? I'll
>>>  >> leave that to others working with that to decide.
>>>  >>
>>>  >> But if we have to decide on a more advanced implementation my 
> choice
>>>  >> would
>>>  >> be logback. My choice is based on two things where one being a 
> past
>>>  >> experience where I developed an audit logging solution based 
> on logback,
>>>  >> where my research showed that log4j had so many deficiencies 
> when it came
>>>  >> to more advanced cases. log4j2 might be a different story with 
> this fixed
>>>  >> though, but I don't see any reason trying something else 
> when there is
>>>  >> proven option. Secondly, I have good confidence in Ceki and 
> that he will
>>>  >> help us out should we need that. I'm not saying those 
> working with log4j2
>>>  >> will not, it's just that I don't know their track 
> record as I know
>>>  >> Ceki's.
>>>  >>
>>>  >> But to repeat myself, going simple in the first release would 
> be so much
>>>  >> better. Then we could get our requirements after this first 
> release and
>>>  >> do
>>>  >> a selection based on them rather than just a gut feeling. 
> Although using
>>>  >> slf4j as the API gives us the technical possibility of 
> switching impl
>>>  >> later
>>>  >> on, I don't think we want that as we can probably expect 
> some people do
>>>  >> solutions expecting a specific impl (as we've seen in the 
> Sonar plugin
>>>  >> for
>>>  >> example).
>>>  >>
>>>  >> /Anders
>>>  >>
>>>  >>
>>>  >> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>  >>
>>>  >> stephen.alan.connolly@gmail.com> wrote:
>>>  >>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>  >>>> 2012/12/9 Olivier Lamy <olamy@apache.org 
> <javascript:;>>:
>>>  >>>>> Perso I'm fine using log4j2.
>>>  >>>>> I use the branch I pushed for some weeks now and 
> I'm happy.
>>>  >>>>> Log4j2 has quickly added a feature I needed and 
> release it.
>>>  >>>>> Furthermore I'm fine working with an Apache 
> community in case of any
>>>  >>>>> issue we could have.
>>>  >>>>
>>>  >>>> I'm not entirely sure I follow where this 
> discussion is actually
>>>  >>>> going,  but I'm firmly opposed
>>>  >>>> to including a brand new logging framework as default 
> in m3.
>>>  >>>
>>>  >>> +1
>>>  >>>
>>>  >>>> Kristian
>>>  >>>>
>>>  >>>> 
> ---------------------------------------------------------------------
>>>  >>>> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.org<javascript:;>
>>>  >>>> For additional commands, e-mail: 
> dev-help@maven.apache.org
>>>  >>
>>>  >> <javascript:;>
>>> 
>>>  Thanks,
>>> 
>>>  Jason
>>> 
>>>  ----------------------------------------------------------
>>>  Jason van Zyl
>>>  Founder & CTO, Sonatype
>>>  Founder,  Apache Maven
>>>  http://twitter.com/jvanzyl
>>>  ---------------------------------------------------------
>>> 
>>>  Three people can keep a secret provided two of them are dead.
>>> 
>>>   -- Benjamin Franklin
>> 
>>  ---------------------------------------------------------------------
>>  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: Logging

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

I cannot
content is here
https://svn.apache.org/repos/infra/websites/production/maven/content/
just need to be checkout a first time.
As some asked to have documentation for plugins for each version we
have a lot of content.
So need some time, so tea time for me.

2012/12/10 Jason van Zyl <ja...@tesla.io>:
> Maybe you can copy over the index.html we can prevent the directory listing from showing up on our home page.
>
> On Dec 10, 2012, at 10:03 AM, Olivier Lamy <ol...@apache.org> wrote:
>
>> http://markmail.org/message/mpgn4yshnt2qmdui
>>
>> 2012/12/10 Jason van Zyl <ja...@tesla.io>:
>>> Not sure what's happening but:
>>>
>>> http://maven.apache.org/developers/dependency-policies.html
>>>
>>> is not there.
>>>
>>> On Dec 10, 2012, at 3:25 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>
>>>> 2012/12/10 Hervé BOUTEMY <he...@free.fr>:
>>>>> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>>>>>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
>>>>>> for the embedding problem, but we're likely to run into issues concurrency
>>>>>> with parallel builds and who knows what else. This will patch/change #5 and
>>>>>> many hours of trying to get SLF4J Simple to work but I think we're pushing
>>>>>> the simple implementation beyond its scope. So I'd just like to put in
>>>>>> Logback and be done with it.
>>>>>>
>>>>>> There are at least three of us opposed to using a new logging framework,
>>>>> logging *implementation*, please, not framework: the framework is slf4j-api,
>>>>> on which our code will have much dependency. The logging implementation is far
>>>>> less invasive choice (even if not completely null).
>>>>>
>>>>>> but I don't think there is anyone against using Logback.
>>>>> why this provocation? (should I say lack of respect for others opinion?)
>>>>>
>>>>>> I honestly don't think
>>>>>> there is any rational argument for not using Logback,  so after doing all
>>>>>> the SLF4J work and making a best effort to use SLF4J Simple I think it's
>>>>>> pointless to pursue that path any longer and put in Logback.
>>>>> we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about
>>>>> this: whatever choice is done, there will be some devs unhappy who will have
>>>>> to live with it
>>>>>
>>>>> notice I won't be able to reply for the next half day, my intent with this
>>>>> reply is just to avoid one more re-spin of a feeling that the vote won't
>>>>> happen and let Olivier once more jump on the case
>>>>> I just hope I won't have to read a lot of replies to this tonight when I'm
>>>>> back from work and loose my time carefully reading if anything new or
>>>>> interesting is written
>>>>>
>>>>
>>>> I have already explained my opinion.
>>>> Folks think log4j2 is "immature" and/or don't have a community of
>>>> various people.
>>>>
>>>> Furthermore it looks it's not anymore possible to use "immature"
>>>> libraries in core (whereas it has been done for more important part:
>>>> sisu or aether).
>>>>
>>>> But now that's not anymore possible...
>>>> Well things evolve and POV can change that's the life....
>>>>
>>>> BTW due to our policy [1] and if I correctly read license here [2] a
>>>> vote is mandatory. (and don't ask me to start this vote :-) ).
>>>>
>>>> Cheers
>>>> --
>>>> Olivier
>>>> [1] http://maven.apache.org/developers/dependency-policies
>>>> [2] http://logback.qos.ch/license.html
>>>>
>>>>> Regards,
>>>>>
>>>>> Hervé
>>>>>
>>>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>>>>> I'm a little bit lost too.
>>>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk
>>>>>>> (for
>>>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>>>> solved only
>>>>>>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>>>>>>> - to be validated by Ceki)
>>>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>>>> I think that everyone's will prefer the first solution if possible but if
>>>>>>> we cannot we'll have the question to select the impl.
>>>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>>>> Like I said in another thread I'll understand if the project decide to
>>>>>>> choose log4j2 even if it is young because we want to support another ASF
>>>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>>>> really good support from its team) but in a general case I would prefer to
>>>>>>> choose logback which is today the reference logging framework (I that case
>>>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>>>
>>>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>>>
>>>>>>> Arnaud
>>>>>>>
>>>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>>>> perspective on this topic.
>>>>>>>>
>>>>>>>> For this first release I would prefer it to not include any of the more
>>>>>>>> advanced slf4j implementations, like a few others have already also
>>>>>>>> stated.
>>>>>>>> Using simple would give us a good start on this new path while we
>>>>>>>> investigate what we and the community want feature wise and then select
>>>>>>>> an
>>>>>>>> implementation based on these requirements. However, if slf4-simple can't
>>>>>>>> do the job of the old behavior when we might not have that option
>>>>>>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>>>>>>> leave that to others working with that to decide.
>>>>>>>>
>>>>>>>> But if we have to decide on a more advanced implementation my choice
>>>>>>>> would
>>>>>>>> be logback. My choice is based on two things where one being a past
>>>>>>>> experience where I developed an audit logging solution based on logback,
>>>>>>>> where my research showed that log4j had so many deficiencies when it came
>>>>>>>> to more advanced cases. log4j2 might be a different story with this fixed
>>>>>>>> though, but I don't see any reason trying something else when there is
>>>>>>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>>>>>>> help us out should we need that. I'm not saying those working with log4j2
>>>>>>>> will not, it's just that I don't know their track record as I know
>>>>>>>> Ceki's.
>>>>>>>>
>>>>>>>> But to repeat myself, going simple in the first release would be so much
>>>>>>>> better. Then we could get our requirements after this first release and
>>>>>>>> do
>>>>>>>> a selection based on them rather than just a gut feeling. Although using
>>>>>>>> slf4j as the API gives us the technical possibility of switching impl
>>>>>>>> later
>>>>>>>> on, I don't think we want that as we can probably expect some people do
>>>>>>>> solutions expecting a specific impl (as we've seen in the Sonar plugin
>>>>>>>> for
>>>>>>>> example).
>>>>>>>>
>>>>>>>> /Anders
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>>>>
>>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>>>>>>> issue we could have.
>>>>>>>>>>
>>>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>>>> going,  but I'm firmly opposed
>>>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>> Kristian
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>> <javascript:;>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder & CTO, Sonatype
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>>
>>>>>> Three people can keep a secret provided two of them are dead.
>>>>>>
>>>>>> -- Benjamin Franklin
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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.
>
>
>
>
>



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

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

Maybe you can copy over the index.html we can prevent the directory listing from showing up on our home page.

On Dec 10, 2012, at 10:03 AM, Olivier Lamy <ol...@apache.org> wrote:

> http://markmail.org/message/mpgn4yshnt2qmdui
> 
> 2012/12/10 Jason van Zyl <ja...@tesla.io>:
>> Not sure what's happening but:
>> 
>> http://maven.apache.org/developers/dependency-policies.html
>> 
>> is not there.
>> 
>> On Dec 10, 2012, at 3:25 AM, Olivier Lamy <ol...@apache.org> wrote:
>> 
>>> 2012/12/10 Hervé BOUTEMY <he...@free.fr>:
>>>> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>>>>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
>>>>> for the embedding problem, but we're likely to run into issues concurrency
>>>>> with parallel builds and who knows what else. This will patch/change #5 and
>>>>> many hours of trying to get SLF4J Simple to work but I think we're pushing
>>>>> the simple implementation beyond its scope. So I'd just like to put in
>>>>> Logback and be done with it.
>>>>> 
>>>>> There are at least three of us opposed to using a new logging framework,
>>>> logging *implementation*, please, not framework: the framework is slf4j-api,
>>>> on which our code will have much dependency. The logging implementation is far
>>>> less invasive choice (even if not completely null).
>>>> 
>>>>> but I don't think there is anyone against using Logback.
>>>> why this provocation? (should I say lack of respect for others opinion?)
>>>> 
>>>>> I honestly don't think
>>>>> there is any rational argument for not using Logback,  so after doing all
>>>>> the SLF4J work and making a best effort to use SLF4J Simple I think it's
>>>>> pointless to pursue that path any longer and put in Logback.
>>>> we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about
>>>> this: whatever choice is done, there will be some devs unhappy who will have
>>>> to live with it
>>>> 
>>>> notice I won't be able to reply for the next half day, my intent with this
>>>> reply is just to avoid one more re-spin of a feeling that the vote won't
>>>> happen and let Olivier once more jump on the case
>>>> I just hope I won't have to read a lot of replies to this tonight when I'm
>>>> back from work and loose my time carefully reading if anything new or
>>>> interesting is written
>>>> 
>>> 
>>> I have already explained my opinion.
>>> Folks think log4j2 is "immature" and/or don't have a community of
>>> various people.
>>> 
>>> Furthermore it looks it's not anymore possible to use "immature"
>>> libraries in core (whereas it has been done for more important part:
>>> sisu or aether).
>>> 
>>> But now that's not anymore possible...
>>> Well things evolve and POV can change that's the life....
>>> 
>>> BTW due to our policy [1] and if I correctly read license here [2] a
>>> vote is mandatory. (and don't ask me to start this vote :-) ).
>>> 
>>> Cheers
>>> --
>>> Olivier
>>> [1] http://maven.apache.org/developers/dependency-policies
>>> [2] http://logback.qos.ch/license.html
>>> 
>>>> Regards,
>>>> 
>>>> Hervé
>>>> 
>>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>>>> I'm a little bit lost too.
>>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk
>>>>>> (for
>>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>>> solved only
>>>>>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>>>>>> - to be validated by Ceki)
>>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>>> I think that everyone's will prefer the first solution if possible but if
>>>>>> we cannot we'll have the question to select the impl.
>>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>>> Like I said in another thread I'll understand if the project decide to
>>>>>> choose log4j2 even if it is young because we want to support another ASF
>>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>>> really good support from its team) but in a general case I would prefer to
>>>>>> choose logback which is today the reference logging framework (I that case
>>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>> 
>>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>> 
>>>>>> Arnaud
>>>>>> 
>>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>>> perspective on this topic.
>>>>>>> 
>>>>>>> For this first release I would prefer it to not include any of the more
>>>>>>> advanced slf4j implementations, like a few others have already also
>>>>>>> stated.
>>>>>>> Using simple would give us a good start on this new path while we
>>>>>>> investigate what we and the community want feature wise and then select
>>>>>>> an
>>>>>>> implementation based on these requirements. However, if slf4-simple can't
>>>>>>> do the job of the old behavior when we might not have that option
>>>>>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>>>>>> leave that to others working with that to decide.
>>>>>>> 
>>>>>>> But if we have to decide on a more advanced implementation my choice
>>>>>>> would
>>>>>>> be logback. My choice is based on two things where one being a past
>>>>>>> experience where I developed an audit logging solution based on logback,
>>>>>>> where my research showed that log4j had so many deficiencies when it came
>>>>>>> to more advanced cases. log4j2 might be a different story with this fixed
>>>>>>> though, but I don't see any reason trying something else when there is
>>>>>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>>>>>> help us out should we need that. I'm not saying those working with log4j2
>>>>>>> will not, it's just that I don't know their track record as I know
>>>>>>> Ceki's.
>>>>>>> 
>>>>>>> But to repeat myself, going simple in the first release would be so much
>>>>>>> better. Then we could get our requirements after this first release and
>>>>>>> do
>>>>>>> a selection based on them rather than just a gut feeling. Although using
>>>>>>> slf4j as the API gives us the technical possibility of switching impl
>>>>>>> later
>>>>>>> on, I don't think we want that as we can probably expect some people do
>>>>>>> solutions expecting a specific impl (as we've seen in the Sonar plugin
>>>>>>> for
>>>>>>> example).
>>>>>>> 
>>>>>>> /Anders
>>>>>>> 
>>>>>>> 
>>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>>> 
>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>>>>>> issue we could have.
>>>>>>>>> 
>>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>>> going,  but I'm firmly opposed
>>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>> 
>>>>>>>> +1
>>>>>>>> 
>>>>>>>>> Kristian
>>>>>>>>> 
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> 
>>>>>>> <javascript:;>
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Jason
>>>>> 
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder & CTO, Sonatype
>>>>> Founder,  Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ---------------------------------------------------------
>>>>> 
>>>>> Three people can keep a secret provided two of them are dead.
>>>>> 
>>>>> -- Benjamin Franklin
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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
>>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> 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: Logging

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

http://markmail.org/message/mpgn4yshnt2qmdui

2012/12/10 Jason van Zyl <ja...@tesla.io>:
> Not sure what's happening but:
>
> http://maven.apache.org/developers/dependency-policies.html
>
> is not there.
>
> On Dec 10, 2012, at 3:25 AM, Olivier Lamy <ol...@apache.org> wrote:
>
>> 2012/12/10 Hervé BOUTEMY <he...@free.fr>:
>>> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>>>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
>>>> for the embedding problem, but we're likely to run into issues concurrency
>>>> with parallel builds and who knows what else. This will patch/change #5 and
>>>> many hours of trying to get SLF4J Simple to work but I think we're pushing
>>>> the simple implementation beyond its scope. So I'd just like to put in
>>>> Logback and be done with it.
>>>>
>>>> There are at least three of us opposed to using a new logging framework,
>>> logging *implementation*, please, not framework: the framework is slf4j-api,
>>> on which our code will have much dependency. The logging implementation is far
>>> less invasive choice (even if not completely null).
>>>
>>>> but I don't think there is anyone against using Logback.
>>> why this provocation? (should I say lack of respect for others opinion?)
>>>
>>>> I honestly don't think
>>>> there is any rational argument for not using Logback,  so after doing all
>>>> the SLF4J work and making a best effort to use SLF4J Simple I think it's
>>>> pointless to pursue that path any longer and put in Logback.
>>> we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about
>>> this: whatever choice is done, there will be some devs unhappy who will have
>>> to live with it
>>>
>>> notice I won't be able to reply for the next half day, my intent with this
>>> reply is just to avoid one more re-spin of a feeling that the vote won't
>>> happen and let Olivier once more jump on the case
>>> I just hope I won't have to read a lot of replies to this tonight when I'm
>>> back from work and loose my time carefully reading if anything new or
>>> interesting is written
>>>
>>
>> I have already explained my opinion.
>> Folks think log4j2 is "immature" and/or don't have a community of
>> various people.
>>
>> Furthermore it looks it's not anymore possible to use "immature"
>> libraries in core (whereas it has been done for more important part:
>> sisu or aether).
>>
>> But now that's not anymore possible...
>> Well things evolve and POV can change that's the life....
>>
>> BTW due to our policy [1] and if I correctly read license here [2] a
>> vote is mandatory. (and don't ask me to start this vote :-) ).
>>
>> Cheers
>> --
>> Olivier
>> [1] http://maven.apache.org/developers/dependency-policies
>> [2] http://logback.qos.ch/license.html
>>
>>> Regards,
>>>
>>> Hervé
>>>
>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>>> I'm a little bit lost too.
>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk
>>>>> (for
>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>> solved only
>>>>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>>>>> - to be validated by Ceki)
>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>> I think that everyone's will prefer the first solution if possible but if
>>>>> we cannot we'll have the question to select the impl.
>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>> Like I said in another thread I'll understand if the project decide to
>>>>> choose log4j2 even if it is young because we want to support another ASF
>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>> really good support from its team) but in a general case I would prefer to
>>>>> choose logback which is today the reference logging framework (I that case
>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>
>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>
>>>>> Arnaud
>>>>>
>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>> perspective on this topic.
>>>>>>
>>>>>> For this first release I would prefer it to not include any of the more
>>>>>> advanced slf4j implementations, like a few others have already also
>>>>>> stated.
>>>>>> Using simple would give us a good start on this new path while we
>>>>>> investigate what we and the community want feature wise and then select
>>>>>> an
>>>>>> implementation based on these requirements. However, if slf4-simple can't
>>>>>> do the job of the old behavior when we might not have that option
>>>>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>>>>> leave that to others working with that to decide.
>>>>>>
>>>>>> But if we have to decide on a more advanced implementation my choice
>>>>>> would
>>>>>> be logback. My choice is based on two things where one being a past
>>>>>> experience where I developed an audit logging solution based on logback,
>>>>>> where my research showed that log4j had so many deficiencies when it came
>>>>>> to more advanced cases. log4j2 might be a different story with this fixed
>>>>>> though, but I don't see any reason trying something else when there is
>>>>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>>>>> help us out should we need that. I'm not saying those working with log4j2
>>>>>> will not, it's just that I don't know their track record as I know
>>>>>> Ceki's.
>>>>>>
>>>>>> But to repeat myself, going simple in the first release would be so much
>>>>>> better. Then we could get our requirements after this first release and
>>>>>> do
>>>>>> a selection based on them rather than just a gut feeling. Although using
>>>>>> slf4j as the API gives us the technical possibility of switching impl
>>>>>> later
>>>>>> on, I don't think we want that as we can probably expect some people do
>>>>>> solutions expecting a specific impl (as we've seen in the Sonar plugin
>>>>>> for
>>>>>> example).
>>>>>>
>>>>>> /Anders
>>>>>>
>>>>>>
>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>>
>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>>>>> issue we could have.
>>>>>>>>
>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>> going,  but I'm firmly opposed
>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>> Kristian
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>> <javascript:;>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>> Three people can keep a secret provided two of them are dead.
>>>>
>>>> -- Benjamin Franklin
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> 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
>
>
>
>
>

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

Re: Logging

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

Not sure what's happening but:

http://maven.apache.org/developers/dependency-policies.html

is not there.

On Dec 10, 2012, at 3:25 AM, Olivier Lamy <ol...@apache.org> wrote:

> 2012/12/10 Hervé BOUTEMY <he...@free.fr>:
>> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
>>> for the embedding problem, but we're likely to run into issues concurrency
>>> with parallel builds and who knows what else. This will patch/change #5 and
>>> many hours of trying to get SLF4J Simple to work but I think we're pushing
>>> the simple implementation beyond its scope. So I'd just like to put in
>>> Logback and be done with it.
>>> 
>>> There are at least three of us opposed to using a new logging framework,
>> logging *implementation*, please, not framework: the framework is slf4j-api,
>> on which our code will have much dependency. The logging implementation is far
>> less invasive choice (even if not completely null).
>> 
>>> but I don't think there is anyone against using Logback.
>> why this provocation? (should I say lack of respect for others opinion?)
>> 
>>> I honestly don't think
>>> there is any rational argument for not using Logback,  so after doing all
>>> the SLF4J work and making a best effort to use SLF4J Simple I think it's
>>> pointless to pursue that path any longer and put in Logback.
>> we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about
>> this: whatever choice is done, there will be some devs unhappy who will have
>> to live with it
>> 
>> notice I won't be able to reply for the next half day, my intent with this
>> reply is just to avoid one more re-spin of a feeling that the vote won't
>> happen and let Olivier once more jump on the case
>> I just hope I won't have to read a lot of replies to this tonight when I'm
>> back from work and loose my time carefully reading if anything new or
>> interesting is written
>> 
> 
> I have already explained my opinion.
> Folks think log4j2 is "immature" and/or don't have a community of
> various people.
> 
> Furthermore it looks it's not anymore possible to use "immature"
> libraries in core (whereas it has been done for more important part:
> sisu or aether).
> 
> But now that's not anymore possible...
> Well things evolve and POV can change that's the life....
> 
> BTW due to our policy [1] and if I correctly read license here [2] a
> vote is mandatory. (and don't ask me to start this vote :-) ).
> 
> Cheers
> --
> Olivier
> [1] http://maven.apache.org/developers/dependency-policies
> [2] http://logback.qos.ch/license.html
> 
>> Regards,
>> 
>> Hervé
>> 
>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>> I'm a little bit lost too.
>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk
>>>> (for
>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>> solved only
>>>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>>>> - to be validated by Ceki)
>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>> I think that everyone's will prefer the first solution if possible but if
>>>> we cannot we'll have the question to select the impl.
>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>> Like I said in another thread I'll understand if the project decide to
>>>> choose log4j2 even if it is young because we want to support another ASF
>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>> really good support from its team) but in a general case I would prefer to
>>>> choose logback which is today the reference logging framework (I that case
>>>> we need to have a PMC vote to accept an external component under EPL
>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>> 
>>>> What do we need (for 3.1.0) ? What do we do ?
>>>> 
>>>> Arnaud
>>>> 
>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>> perspective on this topic.
>>>>> 
>>>>> For this first release I would prefer it to not include any of the more
>>>>> advanced slf4j implementations, like a few others have already also
>>>>> stated.
>>>>> Using simple would give us a good start on this new path while we
>>>>> investigate what we and the community want feature wise and then select
>>>>> an
>>>>> implementation based on these requirements. However, if slf4-simple can't
>>>>> do the job of the old behavior when we might not have that option
>>>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>>>> leave that to others working with that to decide.
>>>>> 
>>>>> But if we have to decide on a more advanced implementation my choice
>>>>> would
>>>>> be logback. My choice is based on two things where one being a past
>>>>> experience where I developed an audit logging solution based on logback,
>>>>> where my research showed that log4j had so many deficiencies when it came
>>>>> to more advanced cases. log4j2 might be a different story with this fixed
>>>>> though, but I don't see any reason trying something else when there is
>>>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>>>> help us out should we need that. I'm not saying those working with log4j2
>>>>> will not, it's just that I don't know their track record as I know
>>>>> Ceki's.
>>>>> 
>>>>> But to repeat myself, going simple in the first release would be so much
>>>>> better. Then we could get our requirements after this first release and
>>>>> do
>>>>> a selection based on them rather than just a gut feeling. Although using
>>>>> slf4j as the API gives us the technical possibility of switching impl
>>>>> later
>>>>> on, I don't think we want that as we can probably expect some people do
>>>>> solutions expecting a specific impl (as we've seen in the Sonar plugin
>>>>> for
>>>>> example).
>>>>> 
>>>>> /Anders
>>>>> 
>>>>> 
>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>> 
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>>>> issue we could have.
>>>>>>> 
>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>> going,  but I'm firmly opposed
>>>>>>> to including a brand new logging framework as default in m3.
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>>> Kristian
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> 
>>>>> <javascript:;>
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>> 
>>> Three people can keep a secret provided two of them are dead.
>>> 
>>> -- Benjamin Franklin
>> 
>> ---------------------------------------------------------------------
>> 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
> 

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

[Mark Struberg <st...@yahoo.de>]

+1

LieGrue,
strub




----- Original Message -----
> From: Kristian Rosenvold <kr...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc: 
> Sent: Monday, December 10, 2012 9:32 AM
> Subject: Re: Logging
> 
> As for options; there is also the option of accepting that the
> technical challenges were slightly larger than anticipated and
> that getting things right make take some more time.
> 
> In this context we could push the slf4j introduction to a "3.1" branch
> and release 3.0.5 now. Or just take the time.
> 
> Kristian
> 
> ---------------------------------------------------------------------
> 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: Logging

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

Curious...reading through all of this it seems there are two primary
situations in play I was wondering if the 'default' logging for console and
embedded need to be so strictly aligned and if you could not just also
publish an distribution or aggregation specifically for embedded that
contains a more friendly default setup.  I know in jetty we push out a
default distribution with barebones logging in it but I know folks that
just take our jetty-distribution's pom.xml, rename it, and add in their own
bits into the right places and roll their own distribution.

dunno if it is viable in this scenario but figured I would throw that out
there

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@gmail.com



On Mon, Dec 10, 2012 at 8:27 AM, Jason van Zyl <ja...@tesla.io> wrote:

> Given the time of year, I think everyone's focus will be elsewhere and
> starting vacations soon so I would rather just wait. I can't even do the
> minimal to use SLF4J Simple until that patch is reviewed and absorbed if it
> is accepted at all because. When I say inefficient it's on the order of
> breaking the performance test harness in SLF4J simple right now, so I'm
> sure my patch will not go in unchanged. I just wanted to prove it can work.
>
> There is also the bit of work Hervé wants to do vis-a-vis isolating the
> SLF4J implementation and so that's going to take a few days anyway.
>
> On Dec 10, 2012, at 3:32 AM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
> > As for options; there is also the option of accepting that the
> > technical challenges were slightly larger than anticipated and
> > that getting things right make take some more time.
> >
> > In this context we could push the slf4j introduction to a "3.1" branch
> > and release 3.0.5 now. Or just take the time.
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > 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
> ---------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
>   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
>
>
>

Re: Logging

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

Given the time of year, I think everyone's focus will be elsewhere and starting vacations soon so I would rather just wait. I can't even do the minimal to use SLF4J Simple until that patch is reviewed and absorbed if it is accepted at all because. When I say inefficient it's on the order of breaking the performance test harness in SLF4J simple right now, so I'm sure my patch will not go in unchanged. I just wanted to prove it can work.

There is also the bit of work Hervé wants to do vis-a-vis isolating the SLF4J implementation and so that's going to take a few days anyway.

On Dec 10, 2012, at 3:32 AM, Kristian Rosenvold <kr...@gmail.com> wrote:

> As for options; there is also the option of accepting that the
> technical challenges were slightly larger than anticipated and
> that getting things right make take some more time.
> 
> In this context we could push the slf4j introduction to a "3.1" branch
> and release 3.0.5 now. Or just take the time.
> 
> Kristian
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance

Re: Logging

[Kristian Rosenvold <kr...@gmail.com>]

I'm thinking we should avoid making the complexity of the decision
increase exponentially ;)

The root cause of my problems have been related to maven verifier and
its capture of logging.

To my best knowledge this is the only real use-case that has trouble,
and if this is the only thing that is keeping us from using
slf4j-simple then it might be time to consider just fixing verifier
and re-releasing that. The /problem/ with "uncontrolled" compatibility
break  is that we're not always aware of the consequences, which is
why it's good to get them into the public view.

But equally I'm even less happy of a solution that initializes logging
via a system property since that blows concurrent embedded invocations
straight out of the water (which is where I want to try taking both
core and surefire IT's soon ;).

Kristian

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

Re: Logging

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

> In this context we could push the slf4j introduction to a "3.1" branch
> and release 3.0.5 now.
>

I'm -1 on that. I think the new architectural changes (injection and slf4j)
makes a good package for v3.1. Introducing injections and bug fixes in
3.0.5 should probably argue for a 3.0.6 release for slf4j. And I firmly
believe we should start use minor versions a little bit more.

/Anders


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

Re: Logging

[Kristian Rosenvold <kr...@gmail.com>]

As for options; there is also the option of accepting that the
technical challenges were slightly larger than anticipated and
that getting things right make take some more time.

In this context we could push the slf4j introduction to a "3.1" branch
and release 3.0.5 now. Or just take the time.

Kristian

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

Re: Logging

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

2012/12/10 Hervé BOUTEMY <he...@free.fr>:
> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
>> for the embedding problem, but we're likely to run into issues concurrency
>> with parallel builds and who knows what else. This will patch/change #5 and
>> many hours of trying to get SLF4J Simple to work but I think we're pushing
>> the simple implementation beyond its scope. So I'd just like to put in
>> Logback and be done with it.
>>
>> There are at least three of us opposed to using a new logging framework,
> logging *implementation*, please, not framework: the framework is slf4j-api,
> on which our code will have much dependency. The logging implementation is far
> less invasive choice (even if not completely null).
>
>> but I don't think there is anyone against using Logback.
> why this provocation? (should I say lack of respect for others opinion?)
>
>> I honestly don't think
>> there is any rational argument for not using Logback,  so after doing all
>> the SLF4J work and making a best effort to use SLF4J Simple I think it's
>> pointless to pursue that path any longer and put in Logback.
> we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about
> this: whatever choice is done, there will be some devs unhappy who will have
> to live with it
>
> notice I won't be able to reply for the next half day, my intent with this
> reply is just to avoid one more re-spin of a feeling that the vote won't
> happen and let Olivier once more jump on the case
> I just hope I won't have to read a lot of replies to this tonight when I'm
> back from work and loose my time carefully reading if anything new or
> interesting is written
>

I have already explained my opinion.
Folks think log4j2 is "immature" and/or don't have a community of
various people.

Furthermore it looks it's not anymore possible to use "immature"
libraries in core (whereas it has been done for more important part:
sisu or aether).

But now that's not anymore possible...
Well things evolve and POV can change that's the life....

BTW due to our policy [1] and if I correctly read license here [2] a
vote is mandatory. (and don't ask me to start this vote :-) ).

Cheers
--
Olivier
[1] http://maven.apache.org/developers/dependency-policies
[2] http://logback.qos.ch/license.html

> Regards,
>
> Hervé
>
>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>> > I'm a little bit lost too.
>> > Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk
>> > (for
>> > many - good - reasons) but the last bug discovered by Kristian can be
>> > solved only
>> > * by having a fix from slf4j (but it isn't sure that the patch makes sense
>> > - to be validated by Ceki)
>> > * or by using a more evolved impl like logback (or log4j ...).
>> > I think that everyone's will prefer the first solution if possible but if
>> > we cannot we'll have the question to select the impl.
>> > Do we need to vote ? Is there really a question logback vs log4j(2) ?
>> > Like I said in another thread I'll understand if the project decide to
>> > choose log4j2 even if it is young because we want to support another ASF
>> > initiative (And I'm sure we won't have to regret it, and we'll have a
>> > really good support from its team) but in a general case I would prefer to
>> > choose logback which is today the reference logging framework (I that case
>> > we need to have a PMC vote to accept an external component under EPL
>> > license http://maven.apache.org/developers/dependency-policies ?).
>> >
>> > What do we need (for 3.1.0) ? What do we do ?
>> >
>> > Arnaud
>> >
>> > On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>> >> Not sure where to get into this thread, but I'd just like to add my
>> >> perspective on this topic.
>> >>
>> >> For this first release I would prefer it to not include any of the more
>> >> advanced slf4j implementations, like a few others have already also
>> >> stated.
>> >> Using simple would give us a good start on this new path while we
>> >> investigate what we and the community want feature wise and then select
>> >> an
>> >> implementation based on these requirements. However, if slf4-simple can't
>> >> do the job of the old behavior when we might not have that option
>> >> unfortunately. Or, possibly we could live with these deficiencies? I'll
>> >> leave that to others working with that to decide.
>> >>
>> >> But if we have to decide on a more advanced implementation my choice
>> >> would
>> >> be logback. My choice is based on two things where one being a past
>> >> experience where I developed an audit logging solution based on logback,
>> >> where my research showed that log4j had so many deficiencies when it came
>> >> to more advanced cases. log4j2 might be a different story with this fixed
>> >> though, but I don't see any reason trying something else when there is
>> >> proven option. Secondly, I have good confidence in Ceki and that he will
>> >> help us out should we need that. I'm not saying those working with log4j2
>> >> will not, it's just that I don't know their track record as I know
>> >> Ceki's.
>> >>
>> >> But to repeat myself, going simple in the first release would be so much
>> >> better. Then we could get our requirements after this first release and
>> >> do
>> >> a selection based on them rather than just a gut feeling. Although using
>> >> slf4j as the API gives us the technical possibility of switching impl
>> >> later
>> >> on, I don't think we want that as we can probably expect some people do
>> >> solutions expecting a specific impl (as we've seen in the Sonar plugin
>> >> for
>> >> example).
>> >>
>> >> /Anders
>> >>
>> >>
>> >> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>> >>
>> >> stephen.alan.connolly@gmail.com> wrote:
>> >>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>> >>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>> >>>>> Perso I'm fine using log4j2.
>> >>>>> I use the branch I pushed for some weeks now and I'm happy.
>> >>>>> Log4j2 has quickly added a feature I needed and release it.
>> >>>>> Furthermore I'm fine working with an Apache community in case of any
>> >>>>> issue we could have.
>> >>>>
>> >>>> I'm not entirely sure I follow where this discussion is actually
>> >>>> going,  but I'm firmly opposed
>> >>>> to including a brand new logging framework as default in m3.
>> >>>
>> >>> +1
>> >>>
>> >>>> Kristian
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> <javascript:;>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> Three people can keep a secret provided two of them are dead.
>>
>>  -- Benjamin Franklin
>
> ---------------------------------------------------------------------
> 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: Logging

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

On Dec 10, 2012, at 2:05 AM, Hervé BOUTEMY <he...@free.fr> wrote:

> Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
>> for the embedding problem, but we're likely to run into issues concurrency
>> with parallel builds and who knows what else. This will patch/change #5 and
>> many hours of trying to get SLF4J Simple to work but I think we're pushing
>> the simple implementation beyond its scope. So I'd just like to put in
>> Logback and be done with it.
>> 
>> There are at least three of us opposed to using a new logging framework,
> logging *implementation*, please, not framework: the framework is slf4j-api, 
> on which our code will have much dependency. The logging implementation is far 
> less invasive choice (even if not completely null).
> 
>> but I don't think there is anyone against using Logback.
> why this provocation? (should I say lack of respect for others opinion?)
> 

Provocation? How do you see after spending a lot of time trying to get SLF4J Simple work, patching it repeatedly, and then coming to the conclusion that SLF4J Simple will is not really sufficient as provocation? In addition to that there is a sentiment at least amongst three of use that picking a new logging implementation isn't sensible and more people that showed a preference for Logback if an implementation had to be chosen. Therefore the only options to move forward are to continue patching SLF4J Simple or use Logback. That's at least the sentiment of anyone who's expressed an opinion.

>> I honestly don't think
>> there is any rational argument for not using Logback,  so after doing all
>> the SLF4J work and making a best effort to use SLF4J Simple I think it's
>> pointless to pursue that path any longer and put in Logback.
> we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about 
> this: whatever choice is done, there will be some devs unhappy who will have 
> to live with it

It's December 10th now, I'll just wait until we decide as nothing much is going to happen between now and the new year. I'll help finish the SLF4J isolation and then I'm going to try some concurrency at which point I think I'll be able to rule out SLF4J Simple. Getting the classloader isolation will probably take another day or two, the concurrency tests probably longer and will require some review. It's also not guaranteed the patches I made to SLF4J Simple make sense so those need to be reviewed as well.

> 
> notice I won't be able to reply for the next half day, my intent with this 
> reply is just to avoid one more re-spin of a feeling that the vote won't 
> happen and let Olivier once more jump on the case
> I just hope I won't have to read a lot of replies to this tonight when I'm 
> back from work and loose my time carefully reading if anything new or 
> interesting is written

No vote is going to happen so there's no rush.

> 
> Regards,
> 
> Hervé
> 
>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>>> I'm a little bit lost too.
>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk
>>> (for
>>> many - good - reasons) but the last bug discovered by Kristian can be
>>> solved only
>>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>>> - to be validated by Ceki)
>>> * or by using a more evolved impl like logback (or log4j ...).
>>> I think that everyone's will prefer the first solution if possible but if
>>> we cannot we'll have the question to select the impl.
>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>> Like I said in another thread I'll understand if the project decide to
>>> choose log4j2 even if it is young because we want to support another ASF
>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>> really good support from its team) but in a general case I would prefer to
>>> choose logback which is today the reference logging framework (I that case
>>> we need to have a PMC vote to accept an external component under EPL
>>> license http://maven.apache.org/developers/dependency-policies ?).
>>> 
>>> What do we need (for 3.1.0) ? What do we do ?
>>> 
>>> Arnaud
>>> 
>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>>> Not sure where to get into this thread, but I'd just like to add my
>>>> perspective on this topic.
>>>> 
>>>> For this first release I would prefer it to not include any of the more
>>>> advanced slf4j implementations, like a few others have already also
>>>> stated.
>>>> Using simple would give us a good start on this new path while we
>>>> investigate what we and the community want feature wise and then select
>>>> an
>>>> implementation based on these requirements. However, if slf4-simple can't
>>>> do the job of the old behavior when we might not have that option
>>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>>> leave that to others working with that to decide.
>>>> 
>>>> But if we have to decide on a more advanced implementation my choice
>>>> would
>>>> be logback. My choice is based on two things where one being a past
>>>> experience where I developed an audit logging solution based on logback,
>>>> where my research showed that log4j had so many deficiencies when it came
>>>> to more advanced cases. log4j2 might be a different story with this fixed
>>>> though, but I don't see any reason trying something else when there is
>>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>>> help us out should we need that. I'm not saying those working with log4j2
>>>> will not, it's just that I don't know their track record as I know
>>>> Ceki's.
>>>> 
>>>> But to repeat myself, going simple in the first release would be so much
>>>> better. Then we could get our requirements after this first release and
>>>> do
>>>> a selection based on them rather than just a gut feeling. Although using
>>>> slf4j as the API gives us the technical possibility of switching impl
>>>> later
>>>> on, I don't think we want that as we can probably expect some people do
>>>> solutions expecting a specific impl (as we've seen in the Sonar plugin
>>>> for
>>>> example).
>>>> 
>>>> /Anders
>>>> 
>>>> 
>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>> 
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>> Perso I'm fine using log4j2.
>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>>> issue we could have.
>>>>>> 
>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>> going,  but I'm firmly opposed
>>>>>> to including a brand new logging framework as default in m3.
>>>>> 
>>>>> +1
>>>>> 
>>>>>> Kristian
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> <javascript:;>
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> Three people can keep a secret provided two of them are dead.
>> 
>> -- Benjamin Franklin
> 
> ---------------------------------------------------------------------
> 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: Logging

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

Le dimanche 9 décembre 2012 20:50:33 Jason van Zyl a écrit :
> I think it's time to stop patching SLF4J Simple. I have an inefficient fix
> for the embedding problem, but we're likely to run into issues concurrency
> with parallel builds and who knows what else. This will patch/change #5 and
> many hours of trying to get SLF4J Simple to work but I think we're pushing
> the simple implementation beyond its scope. So I'd just like to put in
> Logback and be done with it.
> 
> There are at least three of us opposed to using a new logging framework,
logging *implementation*, please, not framework: the framework is slf4j-api, 
on which our code will have much dependency. The logging implementation is far 
less invasive choice (even if not completely null).

> but I don't think there is anyone against using Logback.
why this provocation? (should I say lack of respect for others opinion?)

> I honestly don't think
> there is any rational argument for not using Logback,  so after doing all
> the SLF4J work and making a best effort to use SLF4J Simple I think it's
> pointless to pursue that path any longer and put in Logback.
we'll need to wait for 3.1.1 and a vote to have a chance to stop tension about 
this: whatever choice is done, there will be some devs unhappy who will have 
to live with it

notice I won't be able to reply for the next half day, my intent with this 
reply is just to avoid one more re-spin of a feeling that the vote won't 
happen and let Olivier once more jump on the case
I just hope I won't have to read a lot of replies to this tonight when I'm 
back from work and loose my time carefully reading if anything new or 
interesting is written

Regards,

Hervé

> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
> > I'm a little bit lost too.
> > Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk
> > (for
> > many - good - reasons) but the last bug discovered by Kristian can be
> > solved only
> > * by having a fix from slf4j (but it isn't sure that the patch makes sense
> > - to be validated by Ceki)
> > * or by using a more evolved impl like logback (or log4j ...).
> > I think that everyone's will prefer the first solution if possible but if
> > we cannot we'll have the question to select the impl.
> > Do we need to vote ? Is there really a question logback vs log4j(2) ?
> > Like I said in another thread I'll understand if the project decide to
> > choose log4j2 even if it is young because we want to support another ASF
> > initiative (And I'm sure we won't have to regret it, and we'll have a
> > really good support from its team) but in a general case I would prefer to
> > choose logback which is today the reference logging framework (I that case
> > we need to have a PMC vote to accept an external component under EPL
> > license http://maven.apache.org/developers/dependency-policies ?).
> > 
> > What do we need (for 3.1.0) ? What do we do ?
> > 
> > Arnaud
> > 
> > On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
> >> Not sure where to get into this thread, but I'd just like to add my
> >> perspective on this topic.
> >> 
> >> For this first release I would prefer it to not include any of the more
> >> advanced slf4j implementations, like a few others have already also
> >> stated.
> >> Using simple would give us a good start on this new path while we
> >> investigate what we and the community want feature wise and then select
> >> an
> >> implementation based on these requirements. However, if slf4-simple can't
> >> do the job of the old behavior when we might not have that option
> >> unfortunately. Or, possibly we could live with these deficiencies? I'll
> >> leave that to others working with that to decide.
> >> 
> >> But if we have to decide on a more advanced implementation my choice
> >> would
> >> be logback. My choice is based on two things where one being a past
> >> experience where I developed an audit logging solution based on logback,
> >> where my research showed that log4j had so many deficiencies when it came
> >> to more advanced cases. log4j2 might be a different story with this fixed
> >> though, but I don't see any reason trying something else when there is
> >> proven option. Secondly, I have good confidence in Ceki and that he will
> >> help us out should we need that. I'm not saying those working with log4j2
> >> will not, it's just that I don't know their track record as I know
> >> Ceki's.
> >> 
> >> But to repeat myself, going simple in the first release would be so much
> >> better. Then we could get our requirements after this first release and
> >> do
> >> a selection based on them rather than just a gut feeling. Although using
> >> slf4j as the API gives us the technical possibility of switching impl
> >> later
> >> on, I don't think we want that as we can probably expect some people do
> >> solutions expecting a specific impl (as we've seen in the Sonar plugin
> >> for
> >> example).
> >> 
> >> /Anders
> >> 
> >> 
> >> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
> >> 
> >> stephen.alan.connolly@gmail.com> wrote:
> >>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
> >>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
> >>>>> Perso I'm fine using log4j2.
> >>>>> I use the branch I pushed for some weeks now and I'm happy.
> >>>>> Log4j2 has quickly added a feature I needed and release it.
> >>>>> Furthermore I'm fine working with an Apache community in case of any
> >>>>> issue we could have.
> >>>> 
> >>>> I'm not entirely sure I follow where this discussion is actually
> >>>> going,  but I'm firmly opposed
> >>>> to including a brand new logging framework as default in m3.
> >>> 
> >>> +1
> >>> 
> >>>> Kristian
> >>>> 
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> 
> >> <javascript:;>
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> Three people can keep a secret provided two of them are dead.
> 
>  -- Benjamin Franklin

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

Re: Logging

[John Casey <jd...@commonjava.org>]

Looking at Drools Guvnor, it's ASL...as is the rest of Drools.

And I believe the code they were asking about was related to some new 
features in Guvnor...

So, I guess I'm at a loss for what Mark's concern was. It's still an 
issue for GPL projects, but I haven't had that come up yet.

Understand, I'm not voting either way on this. I don't feel entitled, as 
I haven't had the time to contribute anything more than the occasional 
opinion for things in our actual SCM. Also, I feel like the ship has 
sailed somewhat with Aether, and we're stuck where we are.

But I believe if we're considering third-party integration, we need to 
consider all realistic integration users.



On 12/10/12 2:40 PM, John Casey wrote:
> Reading through the rest of the thread...is this for the default
> implementation we'll ship with maven, or are we talking about skipping
> the slf4j-api abstraction and using logback apis directly?
>
> If it's just the default backend, I'm not concerned at all. If we're
> forcing people to use logback, then to me that's a lot less attractive.
>
> On 12/10/12 2:34 PM, John Casey wrote:
>> On 12/10/12 2:25 PM, Jason van Zyl wrote:
>>> John,
>>>
>>> Eight other projects at Apache use Logback.
>>>
>>> The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any
>>> problems with the EPL. I don't think JBoss would ship a huge product
>>> entirely based on EPL if there were a problem.
>>>
>>> Oracle also now accepts EPL dependencies in their products.
>>>
>>> So what, exactly,  is the potential problem?
>>
>> I'm not on the drools team, I was only trying to help them use the Maven
>> / Aether APIs. Conan mentioned the EPL-ness of Aether as a potential
>> problem for them, and was hoping to use Maven to avoid it until I told
>> him that Maven itself is using Aether. His answer was that they would
>> work around it by isolating the functionality into a separate module
>> with different licensing (or something, I didn't get into the details
>> with him). Either he's not clear on the license interactions, or there
>> is an actual problem that will propagate these licensing complexities
>> out to any GPL project embedding Maven. IANAL.
>>
>> I'm only relating a conversation that was specifically dealing with this
>> issue.
>>
>> Increasingly, my work is with integrating Maven into other tools as
>> well. Personally, I'd prefer something that keeps the licensing clean.
>>
>> AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses.
>> I'm not sure how we deal with this internally, but it's a conversation
>> that comes up periodically. I don't claim to know all the ins and outs,
>> and I think it's not reasonable for someone outside the projects /
>> products themselves to claim they do.
>>
>> I think it comes down to: Are the licenses compatible? If not, are we
>> forcing people to make a decision about taking on extra licensing
>> complexity in order to embed Maven?
>>
>>>
>>> On Dec 10, 2012, at 3:14 PM, John Casey <jd...@commonjava.org> wrote:
>>>
>>>> On 12/9/12 7:50 PM, Jason van Zyl wrote:
>>>>> I think it's time to stop patching SLF4J Simple. I have an
>>>>> inefficient fix for the embedding problem, but we're likely to run
>>>>> into issues concurrency with parallel builds and who knows what
>>>>> else. This will patch/change #5 and many hours of trying to get
>>>>> SLF4J Simple to work but I think we're pushing the simple
>>>>> implementation beyond its scope. So I'd just like to put in Logback
>>>>> and be done with it.
>>>>>
>>>>> There are at least three of us opposed to using a new logging
>>>>> framework, but I don't think there is anyone against using Logback.
>>>>> I honestly don't think there is any rational argument for not using
>>>>> Logback,
>>>>
>>>> I guess m2e and related third-party projects are the things requiring
>>>> these "more evolved" logging options.
>>>>
>>>> One rational argument against including logback is other third-party
>>>> projects that wish to embed Maven but which have licensing conflicts
>>>> with EPL. I had a conversation just the other day with the drools
>>>> folks over this WRT Aether, where its EPL license was a potential
>>>> problem for them. [1]
>>>>
>>>> In considering third-party integration, doesn't it make sense to try
>>>> to stay clear of introducing licensing problems? Isn't that rational?
>>>>
>>>> [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the
>>>> sidebar)
>>>>
>>>>
>>>> so after doing all the SLF4J work and making a best effort to use
>>>> SLF4J Simple I think it's pointless to pursue that path any longer
>>>> and put in Logback.
>>>>>
>>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I'm a little bit lost too.
>>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl
>>>>>> fwk (for
>>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>>> solved only
>>>>>> * by having a fix from slf4j (but it isn't sure that the patch
>>>>>> makes sense
>>>>>> - to be validated by Ceki)
>>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>>> I think that everyone's will prefer the first solution if possible
>>>>>> but if
>>>>>> we cannot we'll have the question to select the impl.
>>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>>> Like I said in another thread I'll understand if the project
>>>>>> decide to
>>>>>> choose log4j2 even if it is young because we want to support
>>>>>> another ASF
>>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>>> really good support from its team) but in a general case I would
>>>>>> prefer to
>>>>>> choose logback which is today the reference logging framework (I
>>>>>> that case
>>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>>
>>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>>
>>>>>> Arnaud
>>>>>>
>>>>>>
>>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net>
>>>>>> wrote:
>>>>>>
>>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>>> perspective on this topic.
>>>>>>>
>>>>>>> For this first release I would prefer it to not include any of the
>>>>>>> more
>>>>>>> advanced slf4j implementations, like a few others have already
>>>>>>> also stated.
>>>>>>> Using simple would give us a good start on this new path while we
>>>>>>> investigate what we and the community want feature wise and then
>>>>>>> select an
>>>>>>> implementation based on these requirements. However, if
>>>>>>> slf4-simple can't
>>>>>>> do the job of the old behavior when we might not have that option
>>>>>>> unfortunately. Or, possibly we could live with these deficiencies?
>>>>>>> I'll
>>>>>>> leave that to others working with that to decide.
>>>>>>>
>>>>>>> But if we have to decide on a more advanced implementation my
>>>>>>> choice would
>>>>>>> be logback. My choice is based on two things where one being a past
>>>>>>> experience where I developed an audit logging solution based on
>>>>>>> logback,
>>>>>>> where my research showed that log4j had so many deficiencies when
>>>>>>> it came
>>>>>>> to more advanced cases. log4j2 might be a different story with
>>>>>>> this fixed
>>>>>>> though, but I don't see any reason trying something else when
>>>>>>> there is
>>>>>>> proven option. Secondly, I have good confidence in Ceki and that
>>>>>>> he will
>>>>>>> help us out should we need that. I'm not saying those working with
>>>>>>> log4j2
>>>>>>> will not, it's just that I don't know their track record as I know
>>>>>>> Ceki's.
>>>>>>>
>>>>>>> But to repeat myself, going simple in the first release would be
>>>>>>> so much
>>>>>>> better. Then we could get our requirements after this first
>>>>>>> release and do
>>>>>>> a selection based on them rather than just a gut feeling. Although
>>>>>>> using
>>>>>>> slf4j as the API gives us the technical possibility of switching
>>>>>>> impl later
>>>>>>> on, I don't think we want that as we can probably expect some
>>>>>>> people do
>>>>>>> solutions expecting a specific impl (as we've seen in the Sonar
>>>>>>> plugin for
>>>>>>> example).
>>>>>>>
>>>>>>> /Anders
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>
>>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>>
>>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>>> Furthermore I'm fine working with an Apache community in case
>>>>>>>>>> of any
>>>>>>>>>> issue we could have.
>>>>>>>>>
>>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>>> going,  but I'm firmly opposed
>>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>>
>>>>>>>>> Kristian
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -----
>>>>>> Arnaud Héritier
>>>>>> http://aheritier.net
>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>> Twitter/Skype : aheritier
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder & CTO, Sonatype
>>>>> Founder,  Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ---------------------------------------------------------
>>>>>
>>>>> Three people can keep a secret provided two of them are dead.
>>>>>
>>>>>   -- Benjamin Franklin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>> GitHub - http://github.com/jdcasey
>>>
>>> Thanks,
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>


-- 
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey

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

Re: Logging

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

yes, I'm stuck with classloader isolation MNG-5406
I don't see how to add a classworlds rule to do that
if you can help me find the proper way to to it, it would be nice, please

Regards,

Hervé

Le dimanche 6 janvier 2013 08:44:25 Jason van Zyl a écrit :
> Cool, do you still need help with the classloader isolation? If not I'll
> move on to the Aether work.
> On Jan 6, 2013, at 5:52 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> > done in 72bdc8602e5112aa273adc46b06d41c41f0f64a8
> > 
> > resetting slf4j factory wasn't sufficient: needed to so the same for
> > slf4j-
> > simple, with same technique
> > 
> > Core ITs now run on my machine: great!
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mercredi 2 janvier 2013 08:20:12 Hervé BOUTEMY a écrit :
> >> yes, Maven isn't an app server, strict security manager shouldn't be an
> >> issue: if someone knows of a situation where it would be, please tell it
> >> :)
> >> 
> >> the very good news with this solution is that it is at slf4j-api level,
> >> not
> >> dependent on logging implementation!
> >> 
> >> I'll look at it in the WE, if nobody beats me at it: the solution is
> >> crystal clear, anybody interested in doing some code in core should be
> >> able to implement it
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le mardi 1 janvier 2013 20:58:18 Jason van Zyl a écrit :
> >>> It is. You create that package structure in your app to access it.
> >>> 
> >>> jvz
> >>> 
> >>> On 2013-01-01, at 8:48 PM, Stephen Connolly
> >> 
> >> <st...@gmail.com> wrote:
> >>>> If I read that right it is accessing a package local method...
> >>>> 
> >>>> That won't work with a security manager in play (not that we have one)
> >>>> [unless we repackage the api jar] but just wondering if that may affect
> >>>> embedded use?
> >>>> 
> >>>> On Tuesday, 1 January 2013, Jason van Zyl wrote:
> >>>>> On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY
> >>>>> <herve.boutemy@free.fr<javascript:;>>>>
> >>>>> 
> >>>>> wrote:
> >>>>>> Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
> >>>>>>> If we want to put aside the debate, Ceki has figured out a way for
> >>>>>>> use
> >>>>> 
> >>>>> SLF4J
> >>>>> 
> >>>>>>> Simple by resetting the streams and logging level. Which I can try
> >>>>>>> if
> >>>>>>> we
> >>>>>>> want to go down that path. I didn't have to do any work in SLF4J
> >>>>>>> myself
> >>>>> 
> >>>>> so
> >>>>> 
> >>>>>>> I'm fine with this approach.
> >>>>>> 
> >>>>>> is there something visible somewhere?
> >>>>>> I didn't find any discussion on slf4j-dev or slf4j-user mailing lists
> >>>>> 
> >>>>> nor any
> >>>>> 
> >>>>>> code in slf4j git repo
> >>>>> 
> >>>>> The suggested solution has existed for two years apparently. There is
> >>>>> no
> >>>>> code that needs to be changed and no features to be added.
> >>>>> 
> >>>>>> resetting TARGET_STREAM in SimpleLogger [1] would require a publid
> >>>>>> method
> >>>>>> or I imagine we can even tweak private field access and private
> >>>>>> method
> >>>>>> invocation through reflection
> >>>>>> 
> >>>>>> how are we supposed to work on this?
> >>>>> 
> >>>>> Just take a look at:
> >>>>> 
> >>>>> 
> >>>>> https://github.com/qos-ch/logback/blob/master/logback-classic/src/test
> >>>>> /
> >>>>> ja
> >>>>> va/org/slf4j/LoggerFactoryFriend.java
> >>>>> 
> >>>>> Pretty straight forward. I don't have time to look at it until Friday
> >>>>> but
> >>>>> if want to implement the reset go for it. I'll ping you on Friday to
> >>>>> see
> >>>>> where you are and help out if you need it.
> >>>>> 
> >>>>>> Regards,
> >>>>>> 
> >>>>>> Hervé
> >>>>>> 
> >>>>>> 
> >>>>>> [1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
> >>>>>> simple/src/main/java/org/slf4j/impl/SimpleLogger.java
> >>>>>> 
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> <javascript:;>
> >>>>>> For additional commands, e-mail:
> >>>>>> dev-help@maven.apache.org<javascript:;>
> >>>>> 
> >>>>> 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
> >> 
> >> ---------------------------------------------------------------------
> >> 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
> ---------------------------------------------------------
> 
> Three people can keep a secret provided two of them are dead.
> 
>  -- Benjamin Franklin

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

Re: Logging

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

Cool, do you still need help with the classloader isolation? If not I'll move on to the Aether work.

On Jan 6, 2013, at 5:52 AM, Hervé BOUTEMY <he...@free.fr> wrote:

> done in 72bdc8602e5112aa273adc46b06d41c41f0f64a8
> 
> resetting slf4j factory wasn't sufficient: needed to so the same for slf4j-
> simple, with same technique
> 
> Core ITs now run on my machine: great!
> 
> Regards,
> 
> Hervé
> 
> Le mercredi 2 janvier 2013 08:20:12 Hervé BOUTEMY a écrit :
>> yes, Maven isn't an app server, strict security manager shouldn't be an
>> issue: if someone knows of a situation where it would be, please tell it :)
>> 
>> the very good news with this solution is that it is at slf4j-api level, not
>> dependent on logging implementation!
>> 
>> I'll look at it in the WE, if nobody beats me at it: the solution is crystal
>> clear, anybody interested in doing some code in core should be able to
>> implement it
>> 
>> Regards,
>> 
>> Hervé
>> 
>> Le mardi 1 janvier 2013 20:58:18 Jason van Zyl a écrit :
>>> It is. You create that package structure in your app to access it.
>>> 
>>> jvz
>>> 
>>> On 2013-01-01, at 8:48 PM, Stephen Connolly
>> 
>> <st...@gmail.com> wrote:
>>>> If I read that right it is accessing a package local method...
>>>> 
>>>> That won't work with a security manager in play (not that we have one)
>>>> [unless we repackage the api jar] but just wondering if that may affect
>>>> embedded use?
>>>> 
>>>> On Tuesday, 1 January 2013, Jason van Zyl wrote:
>>>>> On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY
>>>>> <herve.boutemy@free.fr<javascript:;>>>>
>>>>> 
>>>>> wrote:
>>>>>> Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
>>>>>>> If we want to put aside the debate, Ceki has figured out a way for
>>>>>>> use
>>>>> 
>>>>> SLF4J
>>>>> 
>>>>>>> Simple by resetting the streams and logging level. Which I can try if
>>>>>>> we
>>>>>>> want to go down that path. I didn't have to do any work in SLF4J
>>>>>>> myself
>>>>> 
>>>>> so
>>>>> 
>>>>>>> I'm fine with this approach.
>>>>>> 
>>>>>> is there something visible somewhere?
>>>>>> I didn't find any discussion on slf4j-dev or slf4j-user mailing lists
>>>>> 
>>>>> nor any
>>>>> 
>>>>>> code in slf4j git repo
>>>>> 
>>>>> The suggested solution has existed for two years apparently. There is
>>>>> no
>>>>> code that needs to be changed and no features to be added.
>>>>> 
>>>>>> resetting TARGET_STREAM in SimpleLogger [1] would require a publid
>>>>>> method
>>>>>> or I imagine we can even tweak private field access and private method
>>>>>> invocation through reflection
>>>>>> 
>>>>>> how are we supposed to work on this?
>>>>> 
>>>>> Just take a look at:
>>>>> 
>>>>> 
>>>>> https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/
>>>>> ja
>>>>> va/org/slf4j/LoggerFactoryFriend.java
>>>>> 
>>>>> Pretty straight forward. I don't have time to look at it until Friday
>>>>> but
>>>>> if want to implement the reset go for it. I'll ping you on Friday to
>>>>> see
>>>>> where you are and help out if you need it.
>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Hervé
>>>>>> 
>>>>>> 
>>>>>> [1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
>>>>>> simple/src/main/java/org/slf4j/impl/SimpleLogger.java
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> <javascript:;>
>>>>>> For additional commands, e-mail:
>>>>>> dev-help@maven.apache.org<javascript:;>
>>>>> 
>>>>> 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
>> 
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin

Re: Logging

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

done in 72bdc8602e5112aa273adc46b06d41c41f0f64a8

resetting slf4j factory wasn't sufficient: needed to so the same for slf4j-
simple, with same technique

Core ITs now run on my machine: great!

Regards,

Hervé

Le mercredi 2 janvier 2013 08:20:12 Hervé BOUTEMY a écrit :
> yes, Maven isn't an app server, strict security manager shouldn't be an
> issue: if someone knows of a situation where it would be, please tell it :)
> 
> the very good news with this solution is that it is at slf4j-api level, not
> dependent on logging implementation!
> 
> I'll look at it in the WE, if nobody beats me at it: the solution is crystal
> clear, anybody interested in doing some code in core should be able to
> implement it
> 
> Regards,
> 
> Hervé
> 
> Le mardi 1 janvier 2013 20:58:18 Jason van Zyl a écrit :
> > It is. You create that package structure in your app to access it.
> > 
> > jvz
> > 
> > On 2013-01-01, at 8:48 PM, Stephen Connolly
> 
> <st...@gmail.com> wrote:
> > > If I read that right it is accessing a package local method...
> > > 
> > > That won't work with a security manager in play (not that we have one)
> > > [unless we repackage the api jar] but just wondering if that may affect
> > > embedded use?
> > > 
> > > On Tuesday, 1 January 2013, Jason van Zyl wrote:
> > >> On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY
> > >> <herve.boutemy@free.fr<javascript:;>>>>
> > >> 
> > >> wrote:
> > >>> Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
> > >>>> If we want to put aside the debate, Ceki has figured out a way for
> > >>>> use
> > >> 
> > >> SLF4J
> > >> 
> > >>>> Simple by resetting the streams and logging level. Which I can try if
> > >>>> we
> > >>>> want to go down that path. I didn't have to do any work in SLF4J
> > >>>> myself
> > >> 
> > >> so
> > >> 
> > >>>> I'm fine with this approach.
> > >>> 
> > >>> is there something visible somewhere?
> > >>> I didn't find any discussion on slf4j-dev or slf4j-user mailing lists
> > >> 
> > >> nor any
> > >> 
> > >>> code in slf4j git repo
> > >> 
> > >> The suggested solution has existed for two years apparently. There is
> > >> no
> > >> code that needs to be changed and no features to be added.
> > >> 
> > >>> resetting TARGET_STREAM in SimpleLogger [1] would require a publid
> > >>> method
> > >>> or I imagine we can even tweak private field access and private method
> > >>> invocation through reflection
> > >>> 
> > >>> how are we supposed to work on this?
> > >> 
> > >> Just take a look at:
> > >> 
> > >> 
> > >> https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/
> > >> ja
> > >> va/org/slf4j/LoggerFactoryFriend.java
> > >> 
> > >> Pretty straight forward. I don't have time to look at it until Friday
> > >> but
> > >> if want to implement the reset go for it. I'll ping you on Friday to
> > >> see
> > >> where you are and help out if you need it.
> > >> 
> > >>> Regards,
> > >>> 
> > >>> Hervé
> > >>> 
> > >>> 
> > >>> [1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
> > >>> simple/src/main/java/org/slf4j/impl/SimpleLogger.java
> > >>> 
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> <javascript:;>
> > >>> For additional commands, e-mail:
> > >>> dev-help@maven.apache.org<javascript:;>
> > >> 
> > >> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

Re: Logging

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

yes, Maven isn't an app server, strict security manager shouldn't be an issue: 
if someone knows of a situation where it would be, please tell it :)

the very good news with this solution is that it is at slf4j-api level, not 
dependent on logging implementation!

I'll look at it in the WE, if nobody beats me at it: the solution is crystal 
clear, anybody interested in doing some code in core should be able to 
implement it

Regards,

Hervé

Le mardi 1 janvier 2013 20:58:18 Jason van Zyl a écrit :
> It is. You create that package structure in your app to access it.
> 
> jvz
> 
> On 2013-01-01, at 8:48 PM, Stephen Connolly 
<st...@gmail.com> wrote:
> > If I read that right it is accessing a package local method...
> > 
> > That won't work with a security manager in play (not that we have one)
> > [unless we repackage the api jar] but just wondering if that may affect
> > embedded use?
> > 
> > On Tuesday, 1 January 2013, Jason van Zyl wrote:
> >> On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY
> >> <herve.boutemy@free.fr<javascript:;>>>> 
> >> wrote:
> >>> Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
> >>>> If we want to put aside the debate, Ceki has figured out a way for use
> >> 
> >> SLF4J
> >> 
> >>>> Simple by resetting the streams and logging level. Which I can try if
> >>>> we
> >>>> want to go down that path. I didn't have to do any work in SLF4J myself
> >> 
> >> so
> >> 
> >>>> I'm fine with this approach.
> >>> 
> >>> is there something visible somewhere?
> >>> I didn't find any discussion on slf4j-dev or slf4j-user mailing lists
> >> 
> >> nor any
> >> 
> >>> code in slf4j git repo
> >> 
> >> The suggested solution has existed for two years apparently. There is no
> >> code that needs to be changed and no features to be added.
> >> 
> >>> resetting TARGET_STREAM in SimpleLogger [1] would require a publid
> >>> method
> >>> or I imagine we can even tweak private field access and private method
> >>> invocation through reflection
> >>> 
> >>> how are we supposed to work on this?
> >> 
> >> Just take a look at:
> >> 
> >> 
> >> https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/ja
> >> va/org/slf4j/LoggerFactoryFriend.java
> >> 
> >> Pretty straight forward. I don't have time to look at it until Friday but
> >> if want to implement the reset go for it. I'll ping you on Friday to see
> >> where you are and help out if you need it.
> >> 
> >>> Regards,
> >>> 
> >>> Hervé
> >>> 
> >>> 
> >>> [1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
> >>> simple/src/main/java/org/slf4j/impl/SimpleLogger.java
> >>> 
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> >>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >> 
> >> 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

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

Re: Logging

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

It is. You create that package structure in your app to access it.

jvz

On 2013-01-01, at 8:48 PM, Stephen Connolly <st...@gmail.com> wrote:

> If I read that right it is accessing a package local method...
> 
> That won't work with a security manager in play (not that we have one)
> [unless we repackage the api jar] but just wondering if that may affect
> embedded use?
> 
> On Tuesday, 1 January 2013, Jason van Zyl wrote:
> 
>> 
>> On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY <herve.boutemy@free.fr<javascript:;>>
>> wrote:
>> 
>>> Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
>>>> If we want to put aside the debate, Ceki has figured out a way for use
>> SLF4J
>>>> Simple by resetting the streams and logging level. Which I can try if we
>>>> want to go down that path. I didn't have to do any work in SLF4J myself
>> so
>>>> I'm fine with this approach.
>>> is there something visible somewhere?
>>> I didn't find any discussion on slf4j-dev or slf4j-user mailing lists
>> nor any
>>> code in slf4j git repo
>> 
>> The suggested solution has existed for two years apparently. There is no
>> code that needs to be changed and no features to be added.
>> 
>>> 
>>> resetting TARGET_STREAM in SimpleLogger [1] would require a publid method
>>> or I imagine we can even tweak private field access and private method
>>> invocation through reflection
>>> 
>>> how are we supposed to work on this?
>> 
>> Just take a look at:
>> 
>> 
>> https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/java/org/slf4j/LoggerFactoryFriend.java
>> 
>> Pretty straight forward. I don't have time to look at it until Friday but
>> if want to implement the reset go for it. I'll ping you on Friday to see
>> where you are and help out if you need it.
>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> 
>>> [1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
>>> simple/src/main/java/org/slf4j/impl/SimpleLogger.java
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>> 
>> 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: Logging

[Stephen Connolly <st...@gmail.com>]

If I read that right it is accessing a package local method...

That won't work with a security manager in play (not that we have one)
[unless we repackage the api jar] but just wondering if that may affect
embedded use?

On Tuesday, 1 January 2013, Jason van Zyl wrote:

>
> On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY <herve.boutemy@free.fr<javascript:;>>
> wrote:
>
> > Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
> >> If we want to put aside the debate, Ceki has figured out a way for use
> SLF4J
> >> Simple by resetting the streams and logging level. Which I can try if we
> >> want to go down that path. I didn't have to do any work in SLF4J myself
> so
> >> I'm fine with this approach.
> > is there something visible somewhere?
> > I didn't find any discussion on slf4j-dev or slf4j-user mailing lists
> nor any
> > code in slf4j git repo
>
> The suggested solution has existed for two years apparently. There is no
> code that needs to be changed and no features to be added.
>
> >
> > resetting TARGET_STREAM in SimpleLogger [1] would require a publid method
> > or I imagine we can even tweak private field access and private method
> > invocation through reflection
> >
> > how are we supposed to work on this?
> >
>
> Just take a look at:
>
>
> https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/java/org/slf4j/LoggerFactoryFriend.java
>
> Pretty straight forward. I don't have time to look at it until Friday but
> if want to implement the reset go for it. I'll ping you on Friday to see
> where you are and help out if you need it.
>
> > Regards,
> >
> > Hervé
> >
> >
> > [1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
> > simple/src/main/java/org/slf4j/impl/SimpleLogger.java
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >
>
> 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: Logging

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

On Jan 1, 2013, at 6:15 PM, Hervé BOUTEMY <he...@free.fr> wrote:

> Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
>> If we want to put aside the debate, Ceki has figured out a way for use SLF4J
>> Simple by resetting the streams and logging level. Which I can try if we
>> want to go down that path. I didn't have to do any work in SLF4J myself so
>> I'm fine with this approach.
> is there something visible somewhere?
> I didn't find any discussion on slf4j-dev or slf4j-user mailing lists nor any 
> code in slf4j git repo

The suggested solution has existed for two years apparently. There is no code that needs to be changed and no features to be added.

> 
> resetting TARGET_STREAM in SimpleLogger [1] would require a publid method
> or I imagine we can even tweak private field access and private method 
> invocation through reflection
> 
> how are we supposed to work on this?
> 

Just take a look at:

https://github.com/qos-ch/logback/blob/master/logback-classic/src/test/java/org/slf4j/LoggerFactoryFriend.java

Pretty straight forward. I don't have time to look at it until Friday but if want to implement the reset go for it. I'll ping you on Friday to see where you are and help out if you need it.

> Regards,
> 
> Hervé
> 
> 
> [1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
> simple/src/main/java/org/slf4j/impl/SimpleLogger.java
> 
> ---------------------------------------------------------------------
> 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: Logging

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

Le lundi 24 décembre 2012 09:12:07 Jason van Zyl a écrit :
> If we want to put aside the debate, Ceki has figured out a way for use SLF4J
> Simple by resetting the streams and logging level. Which I can try if we
> want to go down that path. I didn't have to do any work in SLF4J myself so
> I'm fine with this approach.
is there something visible somewhere?
I didn't find any discussion on slf4j-dev or slf4j-user mailing lists nor any 
code in slf4j git repo

resetting TARGET_STREAM in SimpleLogger [1] would require a publid method
or I imagine we can even tweak private field access and private method 
invocation through reflection

how are we supposed to work on this?

Regards,

Hervé


[1] https://github.com/qos-ch/slf4j/blob/master/slf4j-
simple/src/main/java/org/slf4j/impl/SimpleLogger.java

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

Re: Logging

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

Yup, the logback stuff all passes. The grid has been a bit wonky but I'll put a job up there.

On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:

> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
> 
>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>> Now the above could be fixed... but *somebody* needs to write some code
>> to
>>> make them fixed. In the absence of anyone writing such code and
>> committing
>>> it, those branches are dead... as are those choices.
>>> 
>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>> GET THEM WALKING AGAIN
>>> 
>>> That leaves logback and log4j2 on the table...
>>> 
>>> JvZ has said that logback passes the ITs
>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>> for
>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>> ITs.
>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>> jenkins job
>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
> 
> 
> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
> rush to demonstrate Mr Jenkins passing for his branch so he can move up
> from PASSES (unconfirmed) ;-)
> 
> 
>> 
>>> 
>>> I would expect the "other" side in either choice, or an independent third
>>> party (such as Mr Jenkins if he can be made to get the integration tests
>> to
>>> pass at all) to provide confirmation that their "opposition" either has a
>>> branch that passes the integration tests or a claim that they are needing
>>> to give better proof.
>>> 
>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>> other branches is brought back from the dead by somebody writing some
>>> code...)
>> My 0.02 euros.
>> Perso I use log4j2 for months without any issue.
>> And performance are good. Even here with Maven ! (See various reports
>> from folks on the other thread)
>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>> benchmarks depends on various factors (and could be maybe different if
>> runed somewhere else) but that's something to take care.
>> Then Log4j2 is a community developpement effort and have a good
>> license for our Maven.
>> 
> 
> These kinds of things are the things we should be debating... so far I have
> not seen much debate... But I have been waiting to get some options through
> the technical gates first before trying to stir up any non-technical
> debates.
> 
> 
>> 
>>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin

Re: Logging

[Benson Margulies <bi...@gmail.com>]

On Mon, Jan 7, 2013 at 2:07 PM, Jason van Zyl <ja...@tesla.io> wrote:

> That's all reasonable. I will take silence from the rest as tacit
> agreement.
>

+1 to spoil the tacit silence.


>
> On Jan 7, 2013, at 1:33 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> > Hi Jason
> >
> > From what I have gathered from these discussions, we have a majority of
> > people that want to stick with SLF4J Simple for the 3.1.0 release, if
> > all the quirks are ironed out. Judging by Hervé's recent commits this is
> > almost done, except for the class loading isolation in MNG-5406.
> >
> > I think having the 3.1.0 release sit with SLF4J Simple for 6 months is a
> > good idea. That will give it more time in the field, and we can fix any
> > edge cases that might turn up. At the same time it will give us a
> > necessary breather from discussing logging.
> >
> > Having a discussion before selecting some other logging implementation
> > is a must as I see it.
> >
> > As for the licensing "issue", I don't see that as a problem at all. It
> > is just an extra hoop that we have to jump through, if we choose an EPL
> > licensed logging implementation. If we in 6 months time have a majority
> > in favor of an EPL licensed logging, then the vote to add that
> > dependency will pass.
> >
> > Thanks for working on this, and for taking things slow so that everyone
> > that wants to get involved is given the opportunity to do so.
> >
> >
> > On 2013-01-06 17:31, Jason van Zyl wrote:
> >> I believe this is sufficient provided that we agree when any one
> attempts to select the logging framework that there is a discussion.
> >>
> >> As I see it I have been blocked as the person doing the work from
> selecting the implementation I would like because of a rule against EPL
> dependencies which was created for something not related to this. That said
> I understand why it was originally done.
> >>
> >> What I don't want to see if a month from now try someone trying inject
> something that isn't Logback without a discussion because I have a lot to
> say on the matter. So provided there is agreement that if we're choosing
> SLF4J Simple we just leave it there for at least 6 months because the
> discussion will be between Logback and Log4J2 and 1) That's at least how
> long it's going to take for Log4J2 to get to any level of maturity and we
> can see how it's being adopted and 2) I don't really want to talk about
> logging for a while. If we pick SLF4J Simple we stick with it for a while.
> >>
> >> I will express my opinion again that I think Logback is the right
> choice right now, but I'm fine with the agreed upon selection by the group
> to use SLF4J Simple provided this isn't going to be contended for the next
> 6 months. If anyone has any intention of changing the implementation before
> then we should just stop and have the discussion now.
> >>
> >> I also think the PMC should remove the requirement to vote in the use
> of EPL licensed dependencies, there's nothing wrong with the EPL being used
> with the ASL.
> >>
> >> On Dec 28, 2012, at 5:47 AM, Dennis Lundberg <de...@apache.org>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> If SLF4J Simple is now a viable option again, i.e. the problems
> reported
> >>> with concurrency and embedding has been sorted out, then that is the
> >>> obvious choice to me.
> >>>
> >>> On 2012-12-24 15:12, Jason van Zyl wrote:
> >>>> I'm going to push this along and I agree with Stephen insofar as if
> you prefer an implementation then there should be a branch to support that
> preference. Thus far I have not seen anything aside from Stephen's efforts
> which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.
> >>>>
> >>>> If we want to put aside the debate, Ceki has figured out a way for
> use SLF4J Simple by resetting the streams and logging level. Which I can
> try if we want to go down that path. I didn't have to do any work in SLF4J
> myself so I'm fine with this approach.
> >>>>
> >>>> On Dec 17, 2012, at 12:35 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> >>>>
> >>>>> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
> >>>>>
> >>>>>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
> >>>>>>> Now the above could be fixed... but *somebody* needs to write some
> code
> >>>>>> to
> >>>>>>> make them fixed. In the absence of anyone writing such code and
> >>>>>> committing
> >>>>>>> it, those branches are dead... as are those choices.
> >>>>>>>
> >>>>>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN
> CODE TO
> >>>>>>> GET THEM WALKING AGAIN
> >>>>>>>
> >>>>>>> That leaves logback and log4j2 on the table...
> >>>>>>>
> >>>>>>> JvZ has said that logback passes the ITs
> >>>>>>> I have asked quite pointedly that Olivier (or anyone who is
> advocating
> >>>>>> for
> >>>>>>> log4j2) would run the ITs and provide confirmation that log4j2
> passes the
> >>>>>>> ITs.
> >>>>>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
> >>>>>> jenkins job
> >>>>>>
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
> >>>>>
> >>>>>
> >>>>> Thank you. I will take that as PASSES (confirmed)... I assume JvZ
> will now
> >>>>> rush to demonstrate Mr Jenkins passing for his branch so he can move
> up
> >>>>> from PASSES (unconfirmed) ;-)
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I would expect the "other" side in either choice, or an
> independent third
> >>>>>>> party (such as Mr Jenkins if he can be made to get the integration
> tests
> >>>>>> to
> >>>>>>> pass at all) to provide confirmation that their "opposition"
> either has a
> >>>>>>> branch that passes the integration tests or a claim that they are
> needing
> >>>>>>> to give better proof.
> >>>>>>>
> >>>>>>> Now into that maelstrom Benson struck with his $0.02... arguing
> against
> >>>>>>> log4j2 (for now) which kind of leaves us with logback (unless one
> of the
> >>>>>>> other branches is brought back from the dead by somebody writing
> some
> >>>>>>> code...)
> >>>>>> My 0.02 euros.
> >>>>>> Perso I use log4j2 for months without any issue.
> >>>>>> And performance are good. Even here with Maven ! (See various
> reports
> >>>>>> from folks on the other thread)
> >>>>>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
> >>>>>> benchmarks depends on various factors (and could be maybe different
> if
> >>>>>> runed somewhere else) but that's something to take care.
> >>>>>> Then Log4j2 is a community developpement effort and have a good
> >>>>>> license for our Maven.
> >>>>>>
> >>>>>
> >>>>> These kinds of things are the things we should be debating... so far
> I have
> >>>>> not seen much debate... But I have been waiting to get some options
> through
> >>>>> the technical gates first before trying to stir up any non-technical
> >>>>> debates.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jason
> >>>>
> >>>> ----------------------------------------------------------
> >>>> Jason van Zyl
> >>>> Founder & CTO, Sonatype
> >>>> Founder,  Apache Maven
> >>>> http://twitter.com/jvanzyl
> >>>> ---------------------------------------------------------
> >>>>
> >>>> There's no sense in being precise when you don't even know what
> you're talking about.
> >>>>
> >>>> -- John von Neumann
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Dennis Lundberg
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Dennis Lundberg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> The modern conservative is engaged in one of man's oldest exercises in
> moral philosophy; that is,
> the search for a superior moral justification for selfishness.
>
>  -- John Kenneth Galbraith
>
>
>
>
>
>

Re: Logging

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

That's all reasonable. I will take silence from the rest as tacit agreement.

On Jan 7, 2013, at 1:33 PM, Dennis Lundberg <de...@apache.org> wrote:

> Hi Jason
> 
> From what I have gathered from these discussions, we have a majority of
> people that want to stick with SLF4J Simple for the 3.1.0 release, if
> all the quirks are ironed out. Judging by Hervé's recent commits this is
> almost done, except for the class loading isolation in MNG-5406.
> 
> I think having the 3.1.0 release sit with SLF4J Simple for 6 months is a
> good idea. That will give it more time in the field, and we can fix any
> edge cases that might turn up. At the same time it will give us a
> necessary breather from discussing logging.
> 
> Having a discussion before selecting some other logging implementation
> is a must as I see it.
> 
> As for the licensing "issue", I don't see that as a problem at all. It
> is just an extra hoop that we have to jump through, if we choose an EPL
> licensed logging implementation. If we in 6 months time have a majority
> in favor of an EPL licensed logging, then the vote to add that
> dependency will pass.
> 
> Thanks for working on this, and for taking things slow so that everyone
> that wants to get involved is given the opportunity to do so.
> 
> 
> On 2013-01-06 17:31, Jason van Zyl wrote:
>> I believe this is sufficient provided that we agree when any one attempts to select the logging framework that there is a discussion.
>> 
>> As I see it I have been blocked as the person doing the work from selecting the implementation I would like because of a rule against EPL dependencies which was created for something not related to this. That said I understand why it was originally done.
>> 
>> What I don't want to see if a month from now try someone trying inject something that isn't Logback without a discussion because I have a lot to say on the matter. So provided there is agreement that if we're choosing SLF4J Simple we just leave it there for at least 6 months because the discussion will be between Logback and Log4J2 and 1) That's at least how long it's going to take for Log4J2 to get to any level of maturity and we can see how it's being adopted and 2) I don't really want to talk about logging for a while. If we pick SLF4J Simple we stick with it for a while.
>> 
>> I will express my opinion again that I think Logback is the right choice right now, but I'm fine with the agreed upon selection by the group to use SLF4J Simple provided this isn't going to be contended for the next 6 months. If anyone has any intention of changing the implementation before then we should just stop and have the discussion now.
>> 
>> I also think the PMC should remove the requirement to vote in the use of EPL licensed dependencies, there's nothing wrong with the EPL being used with the ASL.
>> 
>> On Dec 28, 2012, at 5:47 AM, Dennis Lundberg <de...@apache.org> wrote:
>> 
>>> Hi,
>>> 
>>> If SLF4J Simple is now a viable option again, i.e. the problems reported
>>> with concurrency and embedding has been sorted out, then that is the
>>> obvious choice to me.
>>> 
>>> On 2012-12-24 15:12, Jason van Zyl wrote:
>>>> I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.
>>>> 
>>>> If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach.
>>>> 
>>>> On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:
>>>> 
>>>>> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
>>>>> 
>>>>>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>>>>>> Now the above could be fixed... but *somebody* needs to write some code
>>>>>> to
>>>>>>> make them fixed. In the absence of anyone writing such code and
>>>>>> committing
>>>>>>> it, those branches are dead... as are those choices.
>>>>>>> 
>>>>>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>>>>>> GET THEM WALKING AGAIN
>>>>>>> 
>>>>>>> That leaves logback and log4j2 on the table...
>>>>>>> 
>>>>>>> JvZ has said that logback passes the ITs
>>>>>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>>>>>> for
>>>>>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>>>>>> ITs.
>>>>>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>>>>>> jenkins job
>>>>>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
>>>>> 
>>>>> 
>>>>> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
>>>>> rush to demonstrate Mr Jenkins passing for his branch so he can move up
>>>>> from PASSES (unconfirmed) ;-)
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> I would expect the "other" side in either choice, or an independent third
>>>>>>> party (such as Mr Jenkins if he can be made to get the integration tests
>>>>>> to
>>>>>>> pass at all) to provide confirmation that their "opposition" either has a
>>>>>>> branch that passes the integration tests or a claim that they are needing
>>>>>>> to give better proof.
>>>>>>> 
>>>>>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>>>>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>>>>>> other branches is brought back from the dead by somebody writing some
>>>>>>> code...)
>>>>>> My 0.02 euros.
>>>>>> Perso I use log4j2 for months without any issue.
>>>>>> And performance are good. Even here with Maven ! (See various reports
>>>>>> from folks on the other thread)
>>>>>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>>>>>> benchmarks depends on various factors (and could be maybe different if
>>>>>> runed somewhere else) but that's something to take care.
>>>>>> Then Log4j2 is a community developpement effort and have a good
>>>>>> license for our Maven.
>>>>>> 
>>>>> 
>>>>> These kinds of things are the things we should be debating... so far I have
>>>>> not seen much debate... But I have been waiting to get some options through
>>>>> the technical gates first before trying to stir up any non-technical
>>>>> debates.
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>> 
>>>> There's no sense in being precise when you don't even know what you're talking about.
>>>> 
>>>> -- John von Neumann
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> Dennis Lundberg
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Dennis Lundberg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, 
the search for a superior moral justification for selfishness.

 -- John Kenneth Galbraith

Re: Logging

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

Hi Jason

>From what I have gathered from these discussions, we have a majority of
people that want to stick with SLF4J Simple for the 3.1.0 release, if
all the quirks are ironed out. Judging by Hervé's recent commits this is
almost done, except for the class loading isolation in MNG-5406.

I think having the 3.1.0 release sit with SLF4J Simple for 6 months is a
good idea. That will give it more time in the field, and we can fix any
edge cases that might turn up. At the same time it will give us a
necessary breather from discussing logging.

Having a discussion before selecting some other logging implementation
is a must as I see it.

As for the licensing "issue", I don't see that as a problem at all. It
is just an extra hoop that we have to jump through, if we choose an EPL
licensed logging implementation. If we in 6 months time have a majority
in favor of an EPL licensed logging, then the vote to add that
dependency will pass.

Thanks for working on this, and for taking things slow so that everyone
that wants to get involved is given the opportunity to do so.


On 2013-01-06 17:31, Jason van Zyl wrote:
> I believe this is sufficient provided that we agree when any one attempts to select the logging framework that there is a discussion.
> 
> As I see it I have been blocked as the person doing the work from selecting the implementation I would like because of a rule against EPL dependencies which was created for something not related to this. That said I understand why it was originally done.
> 
> What I don't want to see if a month from now try someone trying inject something that isn't Logback without a discussion because I have a lot to say on the matter. So provided there is agreement that if we're choosing SLF4J Simple we just leave it there for at least 6 months because the discussion will be between Logback and Log4J2 and 1) That's at least how long it's going to take for Log4J2 to get to any level of maturity and we can see how it's being adopted and 2) I don't really want to talk about logging for a while. If we pick SLF4J Simple we stick with it for a while.
> 
> I will express my opinion again that I think Logback is the right choice right now, but I'm fine with the agreed upon selection by the group to use SLF4J Simple provided this isn't going to be contended for the next 6 months. If anyone has any intention of changing the implementation before then we should just stop and have the discussion now.
> 
> I also think the PMC should remove the requirement to vote in the use of EPL licensed dependencies, there's nothing wrong with the EPL being used with the ASL.
> 
> On Dec 28, 2012, at 5:47 AM, Dennis Lundberg <de...@apache.org> wrote:
> 
>> Hi,
>>
>> If SLF4J Simple is now a viable option again, i.e. the problems reported
>> with concurrency and embedding has been sorted out, then that is the
>> obvious choice to me.
>>
>> On 2012-12-24 15:12, Jason van Zyl wrote:
>>> I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.
>>>
>>> If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach.
>>>
>>> On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:
>>>
>>>> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
>>>>
>>>>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>>>>> Now the above could be fixed... but *somebody* needs to write some code
>>>>> to
>>>>>> make them fixed. In the absence of anyone writing such code and
>>>>> committing
>>>>>> it, those branches are dead... as are those choices.
>>>>>>
>>>>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>>>>> GET THEM WALKING AGAIN
>>>>>>
>>>>>> That leaves logback and log4j2 on the table...
>>>>>>
>>>>>> JvZ has said that logback passes the ITs
>>>>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>>>>> for
>>>>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>>>>> ITs.
>>>>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>>>>> jenkins job
>>>>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
>>>>
>>>>
>>>> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
>>>> rush to demonstrate Mr Jenkins passing for his branch so he can move up
>>>> from PASSES (unconfirmed) ;-)
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> I would expect the "other" side in either choice, or an independent third
>>>>>> party (such as Mr Jenkins if he can be made to get the integration tests
>>>>> to
>>>>>> pass at all) to provide confirmation that their "opposition" either has a
>>>>>> branch that passes the integration tests or a claim that they are needing
>>>>>> to give better proof.
>>>>>>
>>>>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>>>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>>>>> other branches is brought back from the dead by somebody writing some
>>>>>> code...)
>>>>> My 0.02 euros.
>>>>> Perso I use log4j2 for months without any issue.
>>>>> And performance are good. Even here with Maven ! (See various reports
>>>>> from folks on the other thread)
>>>>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>>>>> benchmarks depends on various factors (and could be maybe different if
>>>>> runed somewhere else) but that's something to take care.
>>>>> Then Log4j2 is a community developpement effort and have a good
>>>>> license for our Maven.
>>>>>
>>>>
>>>> These kinds of things are the things we should be debating... so far I have
>>>> not seen much debate... But I have been waiting to get some options through
>>>> the technical gates first before trying to stir up any non-technical
>>>> debates.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> There's no sense in being precise when you don't even know what you're talking about.
>>>
>>> -- John von Neumann
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> -- 
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> 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
> 
> 
> 
> 
> 
> 


-- 
Dennis Lundberg

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

Re: Logging

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

I believe this is sufficient provided that we agree when any one attempts to select the logging framework that there is a discussion.

As I see it I have been blocked as the person doing the work from selecting the implementation I would like because of a rule against EPL dependencies which was created for something not related to this. That said I understand why it was originally done.

What I don't want to see if a month from now try someone trying inject something that isn't Logback without a discussion because I have a lot to say on the matter. So provided there is agreement that if we're choosing SLF4J Simple we just leave it there for at least 6 months because the discussion will be between Logback and Log4J2 and 1) That's at least how long it's going to take for Log4J2 to get to any level of maturity and we can see how it's being adopted and 2) I don't really want to talk about logging for a while. If we pick SLF4J Simple we stick with it for a while.

I will express my opinion again that I think Logback is the right choice right now, but I'm fine with the agreed upon selection by the group to use SLF4J Simple provided this isn't going to be contended for the next 6 months. If anyone has any intention of changing the implementation before then we should just stop and have the discussion now.

I also think the PMC should remove the requirement to vote in the use of EPL licensed dependencies, there's nothing wrong with the EPL being used with the ASL.

On Dec 28, 2012, at 5:47 AM, Dennis Lundberg <de...@apache.org> wrote:

> Hi,
> 
> If SLF4J Simple is now a viable option again, i.e. the problems reported
> with concurrency and embedding has been sorted out, then that is the
> obvious choice to me.
> 
> On 2012-12-24 15:12, Jason van Zyl wrote:
>> I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.
>> 
>> If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach.
>> 
>> On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:
>> 
>>> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
>>> 
>>>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>>>> Now the above could be fixed... but *somebody* needs to write some code
>>>> to
>>>>> make them fixed. In the absence of anyone writing such code and
>>>> committing
>>>>> it, those branches are dead... as are those choices.
>>>>> 
>>>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>>>> GET THEM WALKING AGAIN
>>>>> 
>>>>> That leaves logback and log4j2 on the table...
>>>>> 
>>>>> JvZ has said that logback passes the ITs
>>>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>>>> for
>>>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>>>> ITs.
>>>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>>>> jenkins job
>>>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
>>> 
>>> 
>>> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
>>> rush to demonstrate Mr Jenkins passing for his branch so he can move up
>>> from PASSES (unconfirmed) ;-)
>>> 
>>> 
>>>> 
>>>>> 
>>>>> I would expect the "other" side in either choice, or an independent third
>>>>> party (such as Mr Jenkins if he can be made to get the integration tests
>>>> to
>>>>> pass at all) to provide confirmation that their "opposition" either has a
>>>>> branch that passes the integration tests or a claim that they are needing
>>>>> to give better proof.
>>>>> 
>>>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>>>> other branches is brought back from the dead by somebody writing some
>>>>> code...)
>>>> My 0.02 euros.
>>>> Perso I use log4j2 for months without any issue.
>>>> And performance are good. Even here with Maven ! (See various reports
>>>> from folks on the other thread)
>>>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>>>> benchmarks depends on various factors (and could be maybe different if
>>>> runed somewhere else) but that's something to take care.
>>>> Then Log4j2 is a community developpement effort and have a good
>>>> license for our Maven.
>>>> 
>>> 
>>> These kinds of things are the things we should be debating... so far I have
>>> not seen much debate... But I have been waiting to get some options through
>>> the technical gates first before trying to stir up any non-technical
>>> debates.
>>> 
>>> 
>>>> 
>>>>> 
>>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> There's no sense in being precise when you don't even know what you're talking about.
>> 
>> -- John von Neumann
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Dennis Lundberg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

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

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

Hi,

If SLF4J Simple is now a viable option again, i.e. the problems reported
with concurrency and embedding has been sorted out, then that is the
obvious choice to me.

On 2012-12-24 15:12, Jason van Zyl wrote:
> I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.
> 
> If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach.
> 
> On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:
> 
>> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>>> Now the above could be fixed... but *somebody* needs to write some code
>>> to
>>>> make them fixed. In the absence of anyone writing such code and
>>> committing
>>>> it, those branches are dead... as are those choices.
>>>>
>>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>>> GET THEM WALKING AGAIN
>>>>
>>>> That leaves logback and log4j2 on the table...
>>>>
>>>> JvZ has said that logback passes the ITs
>>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>>> for
>>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>>> ITs.
>>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>>> jenkins job
>>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
>>
>>
>> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
>> rush to demonstrate Mr Jenkins passing for his branch so he can move up
>> from PASSES (unconfirmed) ;-)
>>
>>
>>>
>>>>
>>>> I would expect the "other" side in either choice, or an independent third
>>>> party (such as Mr Jenkins if he can be made to get the integration tests
>>> to
>>>> pass at all) to provide confirmation that their "opposition" either has a
>>>> branch that passes the integration tests or a claim that they are needing
>>>> to give better proof.
>>>>
>>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>>> other branches is brought back from the dead by somebody writing some
>>>> code...)
>>> My 0.02 euros.
>>> Perso I use log4j2 for months without any issue.
>>> And performance are good. Even here with Maven ! (See various reports
>>> from folks on the other thread)
>>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>>> benchmarks depends on various factors (and could be maybe different if
>>> runed somewhere else) but that's something to take care.
>>> Then Log4j2 is a community developpement effort and have a good
>>> license for our Maven.
>>>
>>
>> These kinds of things are the things we should be debating... so far I have
>> not seen much debate... But I have been waiting to get some options through
>> the technical gates first before trying to stir up any non-technical
>> debates.
>>
>>
>>>
>>>>
>>>
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> There's no sense in being precise when you don't even know what you're talking about.
> 
>  -- John von Neumann
> 
> 
> 
> 
> 
> 


-- 
Dennis Lundberg

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

Re: Logging

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

I will try out Ceki's suggestion early next week and report back.

On Dec 24, 2012, at 11:58 AM, Stephen Connolly <st...@gmail.com> wrote:

> Yep if simple is back on the table commit that and let the fight be
> resolved later.
> 
> This logback vs log4j2 debate seems fractious to try and resolve right now
> so sticking to your original plan of the *non-choice* that is simple will
> allow moving forward (though with some cribbing and moaning from the "we
> want coloured logging" brigade)
> 
> ;-)
> 
> On Monday, 24 December 2012, Benson Margulies wrote:
> 
>> On Mon, Dec 24, 2012 at 9:12 AM, Jason van Zyl <jason@tesla.io<javascript:;>>
>> wrote:
>>> I'm going to push this along and I agree with Stephen insofar as if you
>> prefer an implementation then there should be a branch to support that
>> preference. Thus far I have not seen anything aside from Stephen's efforts
>> which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.
>> 
>> You're original plan was to get a release out with Simple and fight
>> later. That would be fine with me.
>> 
>> Based on prior discussions and votes, I don't see anyone vetoing that
>> commit or a vote failing to pass. I'm not sure what I think would
>> happen if you just committed logback or log4j at this point; they seem
>> much of a muchness to me. You prefer logback, but log4j floats certain
>> boats.
>> 
>> 
>>> 
>>> If we want to put aside the debate, Ceki has figured out a way for use
>> SLF4J Simple by resetting the streams and logging level. Which I can try if
>> we want to go down that path. I didn't have to do any work in SLF4J myself
>> so I'm fine with this approach.
>>> 
>>> On Dec 17, 2012, at 12:35 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>> 
>>>> On 17 December 2012 17:28, Olivier Lamy <olamy@apache.org<javascript:;>>
>> wrote:
>>>> 
>>>>> 2012/12/17 Stephen Connolly <stephen.alan.connolly@gmail.com<javascript:;>
>>> :
>>>>>> Now the above could be fixed... but *somebody* needs to write some
>> code
>>>>> to
>>>>>> make them fixed. In the absence of anyone writing such code and
>>>>> committing
>>>>>> it, those branches are dead... as are those choices.
>>>>>> 
>>>>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE
>> TO
>>>>>> GET THEM WALKING AGAIN
>>>>>> 
>>>>>> That leaves logback and log4j2 on the table...
>>>>>> 
>>>>>> JvZ has said that logback passes the ITs
>>>>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>>>>> for
>>>>>> log4j2) would run the ITs and provide confirmation that log4j2 passes
>> the
>>>>>> ITs.
>>>>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>>>>> jenkins job
>>>>> 
>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
>>>> 
>>>> 
>>>> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will
>> now
>>>> rush to demonstrate Mr Jenkins passing for his branch so he can move up
>>>> from PASSES (unconfirmed) ;-)
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> I would expect the "other" side in either choice, or an independent
>> third
>>>>>> party (such as Mr Jenkins if he can be made to get the integration
>> tests
>>>>> to
>>>>>> pass at all) to provide confirmation that their "opposition" either
>> has a
>>>>>> branch that passes the integration tests or a claim that they are
>> needing
>>>>>> to give better proof.
>>>>>> 
>>>>>> Now into that maelstrom Benson struck with his $0.02... arguing
>> against
>>>>>> log4j2 (for now) which kind of leaves us with logback (unless one of
>> the
>>>>>> other branches is brought back from the dead by somebody writing some
>>>>>> code...)
>>>>> My 0.02 euros.
>>>>> Perso I use log4j2 for months without any issue.
>>>>> And performance are good. Even here with Maven ! (See various reports
>>>>> from folks on the other thread)
>>>>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>>>>> benchmarks depends on various factors (and could be maybe different if
>>>>> runed somewhere else) but that's something to take care.
>>>>> Then Log4j2 is a community developpement effort and have a good
>>>>> license for our Maven.
>>>>> 
>>>> 
>>>> These kinds of things are the things we should be debating... so far I
>> have
>>>> not seen much debate... But I have been waiting to get some options
>> through
>>>> the technical gates first before trying to stir up any non-technical
>>>> debates.
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>> 
>>> There's no sense in being precise when you don't even know what you're
>> talking about.
>>> 
>>> -- John von Neumann
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>> 
>> 

Thanks,

Jason

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

[Stephen Connolly <st...@gmail.com>]

Yep if simple is back on the table commit that and let the fight be
resolved later.

This logback vs log4j2 debate seems fractious to try and resolve right now
so sticking to your original plan of the *non-choice* that is simple will
allow moving forward (though with some cribbing and moaning from the "we
want coloured logging" brigade)

;-)

On Monday, 24 December 2012, Benson Margulies wrote:

> On Mon, Dec 24, 2012 at 9:12 AM, Jason van Zyl <jason@tesla.io<javascript:;>>
> wrote:
> > I'm going to push this along and I agree with Stephen insofar as if you
> prefer an implementation then there should be a branch to support that
> preference. Thus far I have not seen anything aside from Stephen's efforts
> which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.
>
> You're original plan was to get a release out with Simple and fight
> later. That would be fine with me.
>
> Based on prior discussions and votes, I don't see anyone vetoing that
> commit or a vote failing to pass. I'm not sure what I think would
> happen if you just committed logback or log4j at this point; they seem
> much of a muchness to me. You prefer logback, but log4j floats certain
> boats.
>
>
> >
> > If we want to put aside the debate, Ceki has figured out a way for use
> SLF4J Simple by resetting the streams and logging level. Which I can try if
> we want to go down that path. I didn't have to do any work in SLF4J myself
> so I'm fine with this approach.
> >
> > On Dec 17, 2012, at 12:35 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >
> >> On 17 December 2012 17:28, Olivier Lamy <olamy@apache.org<javascript:;>>
> wrote:
> >>
> >>> 2012/12/17 Stephen Connolly <stephen.alan.connolly@gmail.com<javascript:;>
> >:
> >>>> Now the above could be fixed... but *somebody* needs to write some
> code
> >>> to
> >>>> make them fixed. In the absence of anyone writing such code and
> >>> committing
> >>>> it, those branches are dead... as are those choices.
> >>>>
> >>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE
> TO
> >>>> GET THEM WALKING AGAIN
> >>>>
> >>>> That leaves logback and log4j2 on the table...
> >>>>
> >>>> JvZ has said that logback passes the ITs
> >>>> I have asked quite pointedly that Olivier (or anyone who is advocating
> >>> for
> >>>> log4j2) would run the ITs and provide confirmation that log4j2 passes
> the
> >>>> ITs.
> >>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
> >>> jenkins job
> >>>
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
> >>
> >>
> >> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will
> now
> >> rush to demonstrate Mr Jenkins passing for his branch so he can move up
> >> from PASSES (unconfirmed) ;-)
> >>
> >>
> >>>
> >>>>
> >>>> I would expect the "other" side in either choice, or an independent
> third
> >>>> party (such as Mr Jenkins if he can be made to get the integration
> tests
> >>> to
> >>>> pass at all) to provide confirmation that their "opposition" either
> has a
> >>>> branch that passes the integration tests or a claim that they are
> needing
> >>>> to give better proof.
> >>>>
> >>>> Now into that maelstrom Benson struck with his $0.02... arguing
> against
> >>>> log4j2 (for now) which kind of leaves us with logback (unless one of
> the
> >>>> other branches is brought back from the dead by somebody writing some
> >>>> code...)
> >>> My 0.02 euros.
> >>> Perso I use log4j2 for months without any issue.
> >>> And performance are good. Even here with Maven ! (See various reports
> >>> from folks on the other thread)
> >>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
> >>> benchmarks depends on various factors (and could be maybe different if
> >>> runed somewhere else) but that's something to take care.
> >>> Then Log4j2 is a community developpement effort and have a good
> >>> license for our Maven.
> >>>
> >>
> >> These kinds of things are the things we should be debating... so far I
> have
> >> not seen much debate... But I have been waiting to get some options
> through
> >> the technical gates first before trying to stir up any non-technical
> >> debates.
> >>
> >>
> >>>
> >>>>
> >>>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > There's no sense in being precise when you don't even know what you're
> talking about.
> >
> >  -- John von Neumann
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

Re: Logging

[Benson Margulies <bi...@gmail.com>]

On Mon, Dec 24, 2012 at 9:12 AM, Jason van Zyl <ja...@tesla.io> wrote:
> I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.

You're original plan was to get a release out with Simple and fight
later. That would be fine with me.

Based on prior discussions and votes, I don't see anyone vetoing that
commit or a vote failing to pass. I'm not sure what I think would
happen if you just committed logback or log4j at this point; they seem
much of a muchness to me. You prefer logback, but log4j floats certain
boats.


>
> If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach.
>
> On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:
>
>> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
>>
>>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>>> Now the above could be fixed... but *somebody* needs to write some code
>>> to
>>>> make them fixed. In the absence of anyone writing such code and
>>> committing
>>>> it, those branches are dead... as are those choices.
>>>>
>>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>>> GET THEM WALKING AGAIN
>>>>
>>>> That leaves logback and log4j2 on the table...
>>>>
>>>> JvZ has said that logback passes the ITs
>>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>>> for
>>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>>> ITs.
>>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>>> jenkins job
>>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
>>
>>
>> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
>> rush to demonstrate Mr Jenkins passing for his branch so he can move up
>> from PASSES (unconfirmed) ;-)
>>
>>
>>>
>>>>
>>>> I would expect the "other" side in either choice, or an independent third
>>>> party (such as Mr Jenkins if he can be made to get the integration tests
>>> to
>>>> pass at all) to provide confirmation that their "opposition" either has a
>>>> branch that passes the integration tests or a claim that they are needing
>>>> to give better proof.
>>>>
>>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>>> other branches is brought back from the dead by somebody writing some
>>>> code...)
>>> My 0.02 euros.
>>> Perso I use log4j2 for months without any issue.
>>> And performance are good. Even here with Maven ! (See various reports
>>> from folks on the other thread)
>>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>>> benchmarks depends on various factors (and could be maybe different if
>>> runed somewhere else) but that's something to take care.
>>> Then Log4j2 is a community developpement effort and have a good
>>> license for our Maven.
>>>
>>
>> These kinds of things are the things we should be debating... so far I have
>> not seen much debate... But I have been waiting to get some options through
>> the technical gates first before trying to stir up any non-technical
>> debates.
>>
>>
>>>
>>>>
>>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> There's no sense in being precise when you don't even know what you're talking about.
>
>  -- John von Neumann
>
>
>
>
>

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

Re: Logging

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

I'm going to push this along and I agree with Stephen insofar as if you prefer an implementation then there should be a branch to support that preference. Thus far I have not seen anything aside from Stephen's efforts which are a PoC so the choice is between SLF4J Simple, Logback and Log4J2.

If we want to put aside the debate, Ceki has figured out a way for use SLF4J Simple by resetting the streams and logging level. Which I can try if we want to go down that path. I didn't have to do any work in SLF4J myself so I'm fine with this approach.

On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:

> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
> 
>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>> Now the above could be fixed... but *somebody* needs to write some code
>> to
>>> make them fixed. In the absence of anyone writing such code and
>> committing
>>> it, those branches are dead... as are those choices.
>>> 
>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>> GET THEM WALKING AGAIN
>>> 
>>> That leaves logback and log4j2 on the table...
>>> 
>>> JvZ has said that logback passes the ITs
>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>> for
>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>> ITs.
>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>> jenkins job
>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
> 
> 
> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
> rush to demonstrate Mr Jenkins passing for his branch so he can move up
> from PASSES (unconfirmed) ;-)
> 
> 
>> 
>>> 
>>> I would expect the "other" side in either choice, or an independent third
>>> party (such as Mr Jenkins if he can be made to get the integration tests
>> to
>>> pass at all) to provide confirmation that their "opposition" either has a
>>> branch that passes the integration tests or a claim that they are needing
>>> to give better proof.
>>> 
>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>> other branches is brought back from the dead by somebody writing some
>>> code...)
>> My 0.02 euros.
>> Perso I use log4j2 for months without any issue.
>> And performance are good. Even here with Maven ! (See various reports
>> from folks on the other thread)
>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>> benchmarks depends on various factors (and could be maybe different if
>> runed somewhere else) but that's something to take care.
>> Then Log4j2 is a community developpement effort and have a good
>> license for our Maven.
>> 
> 
> These kinds of things are the things we should be debating... so far I have
> not seen much debate... But I have been waiting to get some options through
> the technical gates first before trying to stir up any non-technical
> debates.
> 
> 
>> 
>>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

There's no sense in being precise when you don't even know what you're talking about.

 -- John von Neumann

Re: Logging

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

I'll get it up on our Jenkins but here's a run that shows it passes:

http://ci.tesla.io:8080/job/maven-its-logback/jdk=jdk-1.6/20/

On Dec 17, 2012, at 12:35 PM, Stephen Connolly <st...@gmail.com> wrote:

> On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:
> 
>> 2012/12/17 Stephen Connolly <st...@gmail.com>:
>>> Now the above could be fixed... but *somebody* needs to write some code
>> to
>>> make them fixed. In the absence of anyone writing such code and
>> committing
>>> it, those branches are dead... as are those choices.
>>> 
>>> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
>>> GET THEM WALKING AGAIN
>>> 
>>> That leaves logback and log4j2 on the table...
>>> 
>>> JvZ has said that logback passes the ITs
>>> I have asked quite pointedly that Olivier (or anyone who is advocating
>> for
>>> log4j2) would run the ITs and provide confirmation that log4j2 passes the
>>> ITs.
>> branch logging/slf4j-log4j2 pass it (at least locally) and with this
>> jenkins job
>> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
> 
> 
> Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
> rush to demonstrate Mr Jenkins passing for his branch so he can move up
> from PASSES (unconfirmed) ;-)
> 
> 
>> 
>>> 
>>> I would expect the "other" side in either choice, or an independent third
>>> party (such as Mr Jenkins if he can be made to get the integration tests
>> to
>>> pass at all) to provide confirmation that their "opposition" either has a
>>> branch that passes the integration tests or a claim that they are needing
>>> to give better proof.
>>> 
>>> Now into that maelstrom Benson struck with his $0.02... arguing against
>>> log4j2 (for now) which kind of leaves us with logback (unless one of the
>>> other branches is brought back from the dead by somebody writing some
>>> code...)
>> My 0.02 euros.
>> Perso I use log4j2 for months without any issue.
>> And performance are good. Even here with Maven ! (See various reports
>> from folks on the other thread)
>> I read http://logging.apache.org/log4j/2.x/performance.html (agree
>> benchmarks depends on various factors (and could be maybe different if
>> runed somewhere else) but that's something to take care.
>> Then Log4j2 is a community developpement effort and have a good
>> license for our Maven.
>> 
> 
> These kinds of things are the things we should be debating... so far I have
> not seen much debate... But I have been waiting to get some options through
> the technical gates first before trying to stir up any non-technical
> debates.
> 
> 
>> 
>>> 
>> 

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

[Stephen Connolly <st...@gmail.com>]

On 17 December 2012 17:28, Olivier Lamy <ol...@apache.org> wrote:

> 2012/12/17 Stephen Connolly <st...@gmail.com>:
> > Now the above could be fixed... but *somebody* needs to write some code
> to
> > make them fixed. In the absence of anyone writing such code and
> committing
> > it, those branches are dead... as are those choices.
> >
> > IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
> > GET THEM WALKING AGAIN
> >
> > That leaves logback and log4j2 on the table...
> >
> > JvZ has said that logback passes the ITs
> > I have asked quite pointedly that Olivier (or anyone who is advocating
> for
> > log4j2) would run the ITs and provide confirmation that log4j2 passes the
> > ITs.
> branch logging/slf4j-log4j2 pass it (at least locally) and with this
> jenkins job
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/


Thank you. I will take that as PASSES (confirmed)... I assume JvZ will now
rush to demonstrate Mr Jenkins passing for his branch so he can move up
from PASSES (unconfirmed) ;-)


>
> >
> > I would expect the "other" side in either choice, or an independent third
> > party (such as Mr Jenkins if he can be made to get the integration tests
> to
> > pass at all) to provide confirmation that their "opposition" either has a
> > branch that passes the integration tests or a claim that they are needing
> > to give better proof.
> >
> > Now into that maelstrom Benson struck with his $0.02... arguing against
> > log4j2 (for now) which kind of leaves us with logback (unless one of the
> > other branches is brought back from the dead by somebody writing some
> > code...)
> My 0.02 euros.
> Perso I use log4j2 for months without any issue.
> And performance are good. Even here with Maven ! (See various reports
> from folks on the other thread)
> I read http://logging.apache.org/log4j/2.x/performance.html (agree
> benchmarks depends on various factors (and could be maybe different if
> runed somewhere else) but that's something to take care.
> Then Log4j2 is a community developpement effort and have a good
> license for our Maven.
>

These kinds of things are the things we should be debating... so far I have
not seen much debate... But I have been waiting to get some options through
the technical gates first before trying to stir up any non-technical
debates.


>
> >
>

Re: Logging

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

2012/12/17 Stephen Connolly <st...@gmail.com>:
> On 17 December 2012 15:07, Mark Struberg <st...@yahoo.de> wrote:
>
>> Sorry Stephen, I find this comparison unfair.
>>
>
>
> Mark, here is my point.
>
> To move forward on the logging over slf4j plan (A plan you are against, and
> I have not seen any one else support your cause) we need to pick an
> implementation.
>
> Initially JvZ's idea was to avoid picking an implementation (I personally
> suspect because he thought there would be war... but I will leave JvZ to
> confirm or deny my suspicions). That basically means picking slf4j-simple.
>
> Things looked good with slf4j-simple... until some issues in the
> integration tests popped up... JvZ reports that he tried to hobble
> slf4j-simple to the finish line and that he got some patchwork bit of an
> impl to crawl over the finish line (but with an unacceptable performance
> regression)
>
> Then he tried with logback. JvZ is reporting (unconfirmed) that he has
> logback passing all integration tests
> (ed4b5bf98f520d0c9775e5bb6fb7075ac1db5fa0) and on that same branch I and
> IIRC a number of others have not found any performance regressions on those
> sample builds we have tried with.
>
> JvZ started a vote to use logback on that basis.
>
> I corrected the vote to say that we needed to pick an implementation, gave
> some criteria that should be included. Pointed out that the licensing
> requirements should be secondary to the technical requirements. In other
> words *if* there are technical reasons why the best implementation is Cat B
> *then* we should choose the best implementation. [Note: I have not seen
> anyone give technical reasons to favour any implementation over any
> other... I may have missed them]
>
> I knocked together four branches to allow people to compare apples with
> apples, as Olivier's log4j2 branch was a bit old and therefore likely did
> not contain the necessary fixes for the slf4j issues. I also compiled
> branches for JUL and log4j 1.2
>
> I found no major performance issues between the 4 branches and 3.0.4. I
> think I reported this, but I may have forgotten.
>
> Technical issues exist with 2 of the four branches we currently have:
>
> 1. JUL does not support MDC (which is required to deliver improvements in
> the amount of information logged)
> 2. log4j 1.2 needs a proper appender that does not suffer the threading
> issues known with the standard appenders in log4j 1.2 and needs to tweak
> the output so that we have [WARNING] and not [WARN]
>
> Now the above could be fixed... but *somebody* needs to write some code to
> make them fixed. In the absence of anyone writing such code and committing
> it, those branches are dead... as are those choices.
>
> IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
> GET THEM WALKING AGAIN
>
> That leaves logback and log4j2 on the table...
>
> JvZ has said that logback passes the ITs
> I have asked quite pointedly that Olivier (or anyone who is advocating for
> log4j2) would run the ITs and provide confirmation that log4j2 passes the
> ITs.
branch logging/slf4j-log4j2 pass it (at least locally) and with this
jenkins job https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6-log4j2/
>
> I would expect the "other" side in either choice, or an independent third
> party (such as Mr Jenkins if he can be made to get the integration tests to
> pass at all) to provide confirmation that their "opposition" either has a
> branch that passes the integration tests or a claim that they are needing
> to give better proof.
>
> Now into that maelstrom Benson struck with his $0.02... arguing against
> log4j2 (for now) which kind of leaves us with logback (unless one of the
> other branches is brought back from the dead by somebody writing some
> code...)
My 0.02 euros.
Perso I use log4j2 for months without any issue.
And performance are good. Even here with Maven ! (See various reports
from folks on the other thread)
I read http://logging.apache.org/log4j/2.x/performance.html (agree
benchmarks depends on various factors (and could be maybe different if
runed somewhere else) but that's something to take care.
Then Log4j2 is a community developpement effort and have a good
license for our Maven.

>
> Then Olivier decided to propose a 6th way (since we have had so far:
> slf4j-simple; logback; log4j 2.0; log4j 1.2; JUL) namely a plexus-logging
> backed implementation of slf4j-api...
>
> It was to that 6th option that I said he needs to write some code if he
> wants that to be considered. Such an implementation needs to support MDC
> and needs to pass all the integration tests.
>
>
>
>> Please look how much code has been written and is necessary to get slf4j
>> (and any other non MojoLogger impl) really running.
>
>
> The light of a thousand suns that is -X needs to be tamed. MDC (or
> equivalent) is required to tame that beast. JUL is not going to give us
> MDC, so slf4j-api is the only route that I can see to go towards MDC.
>
> What we are talking about is the code to be written to integrate a specific
> implementation into the CLI (or in Olivier's 6th way, that also includes
> the actual (to be written) slf4j-plexus-logging implementation
>
>
>> And for making it fully work it will need even more work because we first
>> need to ship all plugins with an upgraded maven-plugin-plugin build.
>>
>
> I smell FUD again. My understanding is Hervé is working on the solution to
> that.
>
>
>>
>>
>> And most of the log output in projects (surefire) will still funneled via
>> a stdio redirecting, so all the benefit is lost for them, isn't?
>>
>
> Have you run with -X recently?
>
>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>> > From: Stephen Connolly <st...@gmail.com>
>> > To: Maven Developers List <de...@maven.apache.org>
>> > Cc:
>> > Sent: Monday, December 17, 2012 3:58 PM
>> > Subject: Re: Logging
>> >
>> > On 17 December 2012 14:46, Olivier Lamy <ol...@apache.org> wrote:
>> >
>> >>  And what about working on real improvements for users ?
>> >>
>> >>  I see:
>> >>  * incremental build
>> >>  * fixing various bugs on dependency plugin (tree doesn't work well
>> >>  since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
>> >>  old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
>> >>  votes. And IMHO dependency:tree is one of the most important when you
>> >>  want to debug to dependencies.
>> >>  * some jiras we have for core. link
>> >>  (
>> >>
>> >
>> https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel
>> >>  )
>> >>  says 648 open issues ! And they are some very blockers/majors here.
>> >>  * etc...
>> >>
>> >>  Regarding logging, move to slf4j and by default add our own slf4j
>> >>  implementation based on the current plexus logging (then we can simply
>> >>  provide a plugin for users who want to choose an other impl, this
>> >>  plugin will simply update users installations).
>> >>
>> >
>> > That sounds like somebody has to write some code... I don't want to write
>> > some code to handle logging, so I say go for the implementation that
>> > involves not writing code and be done with it. Of the two left on the
>> table
>> > by Benson only one is ready without writing more code... unless somebody
>> > against that option wants to step up and write the code that is ;-)
>> >
>> >
>> >>  Integrators can simply made their own packaging as they do today.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>  2012/12/16 Benson Margulies <bi...@gmail.com>:
>> >>  > Since not much has been heard on the 'pick a logger' question
>> > for some
>> >>  > time, I'm going to stick my neck out and try to summarize some
>> >>  > aspects, in the hopes of discovering how close we are to a consensus.
>> >>  >
>> >>  > In the following, I use the word 'want' to express
>> > *preference*, not
>> >>  > non-negotiable demands.
>> >>  >
>> >>  > We all need: reasonable performance, an acceptable license (i.e.
>> >>  > category A or B), a stable, reliable, logger.
>> >>  >
>> >>  > Various of us want: MDCs, colorization: a package with a community
>> >>  > behind it, an avoidance of of EPL, to use our fellow
>> > Apache-projects'
>> >>  > outputs.
>> >>  >
>> >>  > We know that: java.util.logging isn't going to give us MDCs or
>> >>  > colorization without a great deal of effort. So I'm crossing it
>> > off in
>> >>  > this email.
>> >>  >
>> >>  > Now, I'm going to express an opinion based on all the email
>> > *I've*
>> >>  > seen. I don't claim to be right, but I wonder if people would be
>> >>  > willing to follow my logic.
>> >>  >
>> >>  > Once we eliminate j.u.l from consideration, our choices are logback,
>> >>  > log4j 1.x, and log4j 2.x.
>> >>  >
>> >>  > It seems to me that log4j 2.x is not really ready for us yet, so in
>> >>  > this email I'm crossing it off. If we continue to dither for
>> > another
>> >>  > few months, that might change. If someone disagrees, I'm sure
>> > they'll
>> >>  > respond.
>> >>  >
>> >>  > log4j1.x is the tried and true alternative. Colorization, however,
>> >>  > would require significant effort. Those of us who don't give a fig
>> >>  > about colourization won't be perturbed by this.
>> >>  >
>> >>  > logback, on the other hand, is very widely adopted, and no one seems
>> >>  > to be able to offer any *technical* objection to it. And it gives us
>> >>  > colorization out of the box.
>> >>  >
>> >>  > The objections to logback, then, are cultural, organizational, and/or
>> >>  > related to license.
>> >>  >
>> >>  > In my view, the very broad adoption of logback seems to me to
>> >>  > neutralize the concern that it's a one-man-band. While one person
>> >>  > projects present certain risks in the abstract, this particular one
>> >>  > seems to me not to raise them.
>> >>  >
>> >>  > In my view, objecting based on EPL is, as I wrote once before, not
>> >>  > appropriate. The Maven project erected a barrier to EPL dependencies
>> >>  > to respond to cases in which core Maven functionality was forked and
>> >>  > EPL-ified, or just proposed to be replaced by EPL code. The situation
>> >>  > with logging is simply not analogous. As a project, I don't think
>> > we
>> >>  > need to anticipate wanting to bring the logging system into our
>> >>  > source. Adding a category B logging dependency does not contribute to
>> >>  > the 'hollowing out' of Maven.
>> >>  >
>> >>  > As a Foundation, category B licenses are just as acceptable as
>> >>  > category A licenses as dependencies. (I also wonder why this barrier
>> >>  > was not specifically set up in terms of 'core code replaced by
>> > non-A'
>> >>  > instead of 'EPL').
>> >>  >
>> >>  > If I add this all up, to me it amounts to a test. If some member(s)
>> of
>> >>  > this community really, really, want to take log4j 1.x in order to
>> > 'use
>> >>  > Apache' or 'have a community', I think that those people
>> > should be
>> >>  > willing to step up and *write the code* to make log4j 1.x
>> >>  > feature-equivalent with logback for our purposes. The same logic
>> would
>> >>  > apply to j.u.l, though my impression is that there is no practical
>> >>  > coding path that gets to equivalence.
>> >>  >
>> >>  > I trust that this email will inspire response; perhaps it will
>> inspire
>> >>  > a response that allows us to detect some consensus.
>> >>  >
>> >>  > ---------------------------------------------------------------------
>> >>  > 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
>>
>>



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

[Stephen Connolly <st...@gmail.com>]

On 17 December 2012 15:07, Mark Struberg <st...@yahoo.de> wrote:

> Sorry Stephen, I find this comparison unfair.
>


Mark, here is my point.

To move forward on the logging over slf4j plan (A plan you are against, and
I have not seen any one else support your cause) we need to pick an
implementation.

Initially JvZ's idea was to avoid picking an implementation (I personally
suspect because he thought there would be war... but I will leave JvZ to
confirm or deny my suspicions). That basically means picking slf4j-simple.

Things looked good with slf4j-simple... until some issues in the
integration tests popped up... JvZ reports that he tried to hobble
slf4j-simple to the finish line and that he got some patchwork bit of an
impl to crawl over the finish line (but with an unacceptable performance
regression)

Then he tried with logback. JvZ is reporting (unconfirmed) that he has
logback passing all integration tests
(ed4b5bf98f520d0c9775e5bb6fb7075ac1db5fa0) and on that same branch I and
IIRC a number of others have not found any performance regressions on those
sample builds we have tried with.

JvZ started a vote to use logback on that basis.

I corrected the vote to say that we needed to pick an implementation, gave
some criteria that should be included. Pointed out that the licensing
requirements should be secondary to the technical requirements. In other
words *if* there are technical reasons why the best implementation is Cat B
*then* we should choose the best implementation. [Note: I have not seen
anyone give technical reasons to favour any implementation over any
other... I may have missed them]

I knocked together four branches to allow people to compare apples with
apples, as Olivier's log4j2 branch was a bit old and therefore likely did
not contain the necessary fixes for the slf4j issues. I also compiled
branches for JUL and log4j 1.2

I found no major performance issues between the 4 branches and 3.0.4. I
think I reported this, but I may have forgotten.

Technical issues exist with 2 of the four branches we currently have:

1. JUL does not support MDC (which is required to deliver improvements in
the amount of information logged)
2. log4j 1.2 needs a proper appender that does not suffer the threading
issues known with the standard appenders in log4j 1.2 and needs to tweak
the output so that we have [WARNING] and not [WARN]

Now the above could be fixed... but *somebody* needs to write some code to
make them fixed. In the absence of anyone writing such code and committing
it, those branches are dead... as are those choices.

IF YOU WANT TO SPONSOR ONE OF THOSE BRANCHES THEN WRITE THE DAMN CODE TO
GET THEM WALKING AGAIN

That leaves logback and log4j2 on the table...

JvZ has said that logback passes the ITs
I have asked quite pointedly that Olivier (or anyone who is advocating for
log4j2) would run the ITs and provide confirmation that log4j2 passes the
ITs.

I would expect the "other" side in either choice, or an independent third
party (such as Mr Jenkins if he can be made to get the integration tests to
pass at all) to provide confirmation that their "opposition" either has a
branch that passes the integration tests or a claim that they are needing
to give better proof.

Now into that maelstrom Benson struck with his $0.02... arguing against
log4j2 (for now) which kind of leaves us with logback (unless one of the
other branches is brought back from the dead by somebody writing some
code...)

Then Olivier decided to propose a 6th way (since we have had so far:
slf4j-simple; logback; log4j 2.0; log4j 1.2; JUL) namely a plexus-logging
backed implementation of slf4j-api...

It was to that 6th option that I said he needs to write some code if he
wants that to be considered. Such an implementation needs to support MDC
and needs to pass all the integration tests.



> Please look how much code has been written and is necessary to get slf4j
> (and any other non MojoLogger impl) really running.


The light of a thousand suns that is -X needs to be tamed. MDC (or
equivalent) is required to tame that beast. JUL is not going to give us
MDC, so slf4j-api is the only route that I can see to go towards MDC.

What we are talking about is the code to be written to integrate a specific
implementation into the CLI (or in Olivier's 6th way, that also includes
the actual (to be written) slf4j-plexus-logging implementation


> And for making it fully work it will need even more work because we first
> need to ship all plugins with an upgraded maven-plugin-plugin build.
>

I smell FUD again. My understanding is Hervé is working on the solution to
that.


>
>
> And most of the log output in projects (surefire) will still funneled via
> a stdio redirecting, so all the benefit is lost for them, isn't?
>

Have you run with -X recently?


>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Stephen Connolly <st...@gmail.com>
> > To: Maven Developers List <de...@maven.apache.org>
> > Cc:
> > Sent: Monday, December 17, 2012 3:58 PM
> > Subject: Re: Logging
> >
> > On 17 December 2012 14:46, Olivier Lamy <ol...@apache.org> wrote:
> >
> >>  And what about working on real improvements for users ?
> >>
> >>  I see:
> >>  * incremental build
> >>  * fixing various bugs on dependency plugin (tree doesn't work well
> >>  since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
> >>  old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
> >>  votes. And IMHO dependency:tree is one of the most important when you
> >>  want to debug to dependencies.
> >>  * some jiras we have for core. link
> >>  (
> >>
> >
> https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel
> >>  )
> >>  says 648 open issues ! And they are some very blockers/majors here.
> >>  * etc...
> >>
> >>  Regarding logging, move to slf4j and by default add our own slf4j
> >>  implementation based on the current plexus logging (then we can simply
> >>  provide a plugin for users who want to choose an other impl, this
> >>  plugin will simply update users installations).
> >>
> >
> > That sounds like somebody has to write some code... I don't want to write
> > some code to handle logging, so I say go for the implementation that
> > involves not writing code and be done with it. Of the two left on the
> table
> > by Benson only one is ready without writing more code... unless somebody
> > against that option wants to step up and write the code that is ;-)
> >
> >
> >>  Integrators can simply made their own packaging as they do today.
> >>
> >>
> >>
> >>
> >>
> >>  2012/12/16 Benson Margulies <bi...@gmail.com>:
> >>  > Since not much has been heard on the 'pick a logger' question
> > for some
> >>  > time, I'm going to stick my neck out and try to summarize some
> >>  > aspects, in the hopes of discovering how close we are to a consensus.
> >>  >
> >>  > In the following, I use the word 'want' to express
> > *preference*, not
> >>  > non-negotiable demands.
> >>  >
> >>  > We all need: reasonable performance, an acceptable license (i.e.
> >>  > category A or B), a stable, reliable, logger.
> >>  >
> >>  > Various of us want: MDCs, colorization: a package with a community
> >>  > behind it, an avoidance of of EPL, to use our fellow
> > Apache-projects'
> >>  > outputs.
> >>  >
> >>  > We know that: java.util.logging isn't going to give us MDCs or
> >>  > colorization without a great deal of effort. So I'm crossing it
> > off in
> >>  > this email.
> >>  >
> >>  > Now, I'm going to express an opinion based on all the email
> > *I've*
> >>  > seen. I don't claim to be right, but I wonder if people would be
> >>  > willing to follow my logic.
> >>  >
> >>  > Once we eliminate j.u.l from consideration, our choices are logback,
> >>  > log4j 1.x, and log4j 2.x.
> >>  >
> >>  > It seems to me that log4j 2.x is not really ready for us yet, so in
> >>  > this email I'm crossing it off. If we continue to dither for
> > another
> >>  > few months, that might change. If someone disagrees, I'm sure
> > they'll
> >>  > respond.
> >>  >
> >>  > log4j1.x is the tried and true alternative. Colorization, however,
> >>  > would require significant effort. Those of us who don't give a fig
> >>  > about colourization won't be perturbed by this.
> >>  >
> >>  > logback, on the other hand, is very widely adopted, and no one seems
> >>  > to be able to offer any *technical* objection to it. And it gives us
> >>  > colorization out of the box.
> >>  >
> >>  > The objections to logback, then, are cultural, organizational, and/or
> >>  > related to license.
> >>  >
> >>  > In my view, the very broad adoption of logback seems to me to
> >>  > neutralize the concern that it's a one-man-band. While one person
> >>  > projects present certain risks in the abstract, this particular one
> >>  > seems to me not to raise them.
> >>  >
> >>  > In my view, objecting based on EPL is, as I wrote once before, not
> >>  > appropriate. The Maven project erected a barrier to EPL dependencies
> >>  > to respond to cases in which core Maven functionality was forked and
> >>  > EPL-ified, or just proposed to be replaced by EPL code. The situation
> >>  > with logging is simply not analogous. As a project, I don't think
> > we
> >>  > need to anticipate wanting to bring the logging system into our
> >>  > source. Adding a category B logging dependency does not contribute to
> >>  > the 'hollowing out' of Maven.
> >>  >
> >>  > As a Foundation, category B licenses are just as acceptable as
> >>  > category A licenses as dependencies. (I also wonder why this barrier
> >>  > was not specifically set up in terms of 'core code replaced by
> > non-A'
> >>  > instead of 'EPL').
> >>  >
> >>  > If I add this all up, to me it amounts to a test. If some member(s)
> of
> >>  > this community really, really, want to take log4j 1.x in order to
> > 'use
> >>  > Apache' or 'have a community', I think that those people
> > should be
> >>  > willing to step up and *write the code* to make log4j 1.x
> >>  > feature-equivalent with logback for our purposes. The same logic
> would
> >>  > apply to j.u.l, though my impression is that there is no practical
> >>  > coding path that gets to equivalence.
> >>  >
> >>  > I trust that this email will inspire response; perhaps it will
> inspire
> >>  > a response that allows us to detect some consensus.
> >>  >
> >>  > ---------------------------------------------------------------------
> >>  > 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: Logging

[Mark Struberg <st...@yahoo.de>]

Sorry Stephen, I find this comparison unfair. 
Please look how much code has been written and is necessary to get slf4j (and any other non MojoLogger impl) really running. And for making it fully work it will need even more work because we first need to ship all plugins with an upgraded maven-plugin-plugin build.


And most of the log output in projects (surefire) will still funneled via a stdio redirecting, so all the benefit is lost for them, isn't?

LieGrue,
strub



----- Original Message -----
> From: Stephen Connolly <st...@gmail.com>
> To: Maven Developers List <de...@maven.apache.org>
> Cc: 
> Sent: Monday, December 17, 2012 3:58 PM
> Subject: Re: Logging
> 
> On 17 December 2012 14:46, Olivier Lamy <ol...@apache.org> wrote:
> 
>>  And what about working on real improvements for users ?
>> 
>>  I see:
>>  * incremental build
>>  * fixing various bugs on dependency plugin (tree doesn't work well
>>  since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
>>  old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
>>  votes. And IMHO dependency:tree is one of the most important when you
>>  want to debug to dependencies.
>>  * some jiras we have for core. link
>>  (
>> 
> https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel
>>  )
>>  says 648 open issues ! And they are some very blockers/majors here.
>>  * etc...
>> 
>>  Regarding logging, move to slf4j and by default add our own slf4j
>>  implementation based on the current plexus logging (then we can simply
>>  provide a plugin for users who want to choose an other impl, this
>>  plugin will simply update users installations).
>> 
> 
> That sounds like somebody has to write some code... I don't want to write
> some code to handle logging, so I say go for the implementation that
> involves not writing code and be done with it. Of the two left on the table
> by Benson only one is ready without writing more code... unless somebody
> against that option wants to step up and write the code that is ;-)
> 
> 
>>  Integrators can simply made their own packaging as they do today.
>> 
>> 
>> 
>> 
>> 
>>  2012/12/16 Benson Margulies <bi...@gmail.com>:
>>  > Since not much has been heard on the 'pick a logger' question 
> for some
>>  > time, I'm going to stick my neck out and try to summarize some
>>  > aspects, in the hopes of discovering how close we are to a consensus.
>>  >
>>  > In the following, I use the word 'want' to express 
> *preference*, not
>>  > non-negotiable demands.
>>  >
>>  > We all need: reasonable performance, an acceptable license (i.e.
>>  > category A or B), a stable, reliable, logger.
>>  >
>>  > Various of us want: MDCs, colorization: a package with a community
>>  > behind it, an avoidance of of EPL, to use our fellow 
> Apache-projects'
>>  > outputs.
>>  >
>>  > We know that: java.util.logging isn't going to give us MDCs or
>>  > colorization without a great deal of effort. So I'm crossing it 
> off in
>>  > this email.
>>  >
>>  > Now, I'm going to express an opinion based on all the email 
> *I've*
>>  > seen. I don't claim to be right, but I wonder if people would be
>>  > willing to follow my logic.
>>  >
>>  > Once we eliminate j.u.l from consideration, our choices are logback,
>>  > log4j 1.x, and log4j 2.x.
>>  >
>>  > It seems to me that log4j 2.x is not really ready for us yet, so in
>>  > this email I'm crossing it off. If we continue to dither for 
> another
>>  > few months, that might change. If someone disagrees, I'm sure 
> they'll
>>  > respond.
>>  >
>>  > log4j1.x is the tried and true alternative. Colorization, however,
>>  > would require significant effort. Those of us who don't give a fig
>>  > about colourization won't be perturbed by this.
>>  >
>>  > logback, on the other hand, is very widely adopted, and no one seems
>>  > to be able to offer any *technical* objection to it. And it gives us
>>  > colorization out of the box.
>>  >
>>  > The objections to logback, then, are cultural, organizational, and/or
>>  > related to license.
>>  >
>>  > In my view, the very broad adoption of logback seems to me to
>>  > neutralize the concern that it's a one-man-band. While one person
>>  > projects present certain risks in the abstract, this particular one
>>  > seems to me not to raise them.
>>  >
>>  > In my view, objecting based on EPL is, as I wrote once before, not
>>  > appropriate. The Maven project erected a barrier to EPL dependencies
>>  > to respond to cases in which core Maven functionality was forked and
>>  > EPL-ified, or just proposed to be replaced by EPL code. The situation
>>  > with logging is simply not analogous. As a project, I don't think 
> we
>>  > need to anticipate wanting to bring the logging system into our
>>  > source. Adding a category B logging dependency does not contribute to
>>  > the 'hollowing out' of Maven.
>>  >
>>  > As a Foundation, category B licenses are just as acceptable as
>>  > category A licenses as dependencies. (I also wonder why this barrier
>>  > was not specifically set up in terms of 'core code replaced by 
> non-A'
>>  > instead of 'EPL').
>>  >
>>  > If I add this all up, to me it amounts to a test. If some member(s) of
>>  > this community really, really, want to take log4j 1.x in order to 
> 'use
>>  > Apache' or 'have a community', I think that those people 
> should be
>>  > willing to step up and *write the code* to make log4j 1.x
>>  > feature-equivalent with logback for our purposes. The same logic would
>>  > apply to j.u.l, though my impression is that there is no practical
>>  > coding path that gets to equivalence.
>>  >
>>  > I trust that this email will inspire response; perhaps it will inspire
>>  > a response that allows us to detect some consensus.
>>  >
>>  > ---------------------------------------------------------------------
>>  > 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: Logging

[Stephen Connolly <st...@gmail.com>]

On 17 December 2012 14:46, Olivier Lamy <ol...@apache.org> wrote:

> And what about working on real improvements for users ?
>
> I see:
> * incremental build
> * fixing various bugs on dependency plugin (tree doesn't work well
> since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
> old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
> votes. And IMHO dependency:tree is one of the most important when you
> want to debug to dependencies.
> * some jiras we have for core. link
> (
> https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel
> )
> says 648 open issues ! And they are some very blockers/majors here.
> * etc...
>
> Regarding logging, move to slf4j and by default add our own slf4j
> implementation based on the current plexus logging (then we can simply
> provide a plugin for users who want to choose an other impl, this
> plugin will simply update users installations).
>

That sounds like somebody has to write some code... I don't want to write
some code to handle logging, so I say go for the implementation that
involves not writing code and be done with it. Of the two left on the table
by Benson only one is ready without writing more code... unless somebody
against that option wants to step up and write the code that is ;-)


> Integrators can simply made their own packaging as they do today.
>
>
>
>
>
> 2012/12/16 Benson Margulies <bi...@gmail.com>:
> > Since not much has been heard on the 'pick a logger' question for some
> > time, I'm going to stick my neck out and try to summarize some
> > aspects, in the hopes of discovering how close we are to a consensus.
> >
> > In the following, I use the word 'want' to express *preference*, not
> > non-negotiable demands.
> >
> > We all need: reasonable performance, an acceptable license (i.e.
> > category A or B), a stable, reliable, logger.
> >
> > Various of us want: MDCs, colorization: a package with a community
> > behind it, an avoidance of of EPL, to use our fellow Apache-projects'
> > outputs.
> >
> > We know that: java.util.logging isn't going to give us MDCs or
> > colorization without a great deal of effort. So I'm crossing it off in
> > this email.
> >
> > Now, I'm going to express an opinion based on all the email *I've*
> > seen. I don't claim to be right, but I wonder if people would be
> > willing to follow my logic.
> >
> > Once we eliminate j.u.l from consideration, our choices are logback,
> > log4j 1.x, and log4j 2.x.
> >
> > It seems to me that log4j 2.x is not really ready for us yet, so in
> > this email I'm crossing it off. If we continue to dither for another
> > few months, that might change. If someone disagrees, I'm sure they'll
> > respond.
> >
> > log4j1.x is the tried and true alternative. Colorization, however,
> > would require significant effort. Those of us who don't give a fig
> > about colourization won't be perturbed by this.
> >
> > logback, on the other hand, is very widely adopted, and no one seems
> > to be able to offer any *technical* objection to it. And it gives us
> > colorization out of the box.
> >
> > The objections to logback, then, are cultural, organizational, and/or
> > related to license.
> >
> > In my view, the very broad adoption of logback seems to me to
> > neutralize the concern that it's a one-man-band. While one person
> > projects present certain risks in the abstract, this particular one
> > seems to me not to raise them.
> >
> > In my view, objecting based on EPL is, as I wrote once before, not
> > appropriate. The Maven project erected a barrier to EPL dependencies
> > to respond to cases in which core Maven functionality was forked and
> > EPL-ified, or just proposed to be replaced by EPL code. The situation
> > with logging is simply not analogous. As a project, I don't think we
> > need to anticipate wanting to bring the logging system into our
> > source. Adding a category B logging dependency does not contribute to
> > the 'hollowing out' of Maven.
> >
> > As a Foundation, category B licenses are just as acceptable as
> > category A licenses as dependencies. (I also wonder why this barrier
> > was not specifically set up in terms of 'core code replaced by non-A'
> > instead of 'EPL').
> >
> > If I add this all up, to me it amounts to a test. If some member(s) of
> > this community really, really, want to take log4j 1.x in order to 'use
> > Apache' or 'have a community', I think that those people should be
> > willing to step up and *write the code* to make log4j 1.x
> > feature-equivalent with logback for our purposes. The same logic would
> > apply to j.u.l, though my impression is that there is no practical
> > coding path that gets to equivalence.
> >
> > I trust that this email will inspire response; perhaps it will inspire
> > a response that allows us to detect some consensus.
> >
> > ---------------------------------------------------------------------
> > 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: Logging

[Benson Margulies <bi...@gmail.com>]

On Mon, Dec 17, 2012 at 9:46 AM, Olivier Lamy <ol...@apache.org> wrote:
> And what about working on real improvements for users ?

I don't follow. I sent an email that attempts to bring this debate to
a close so that, in fact, we can get a release out and get on with
other projects, of which all of the below are good things. How is it
my responsibility to also organize all of that?

I see the torrent of crap that spews out of -X as a major usability
problem with maven -- a far more serious one, in my opinion, that the
lack of incrementality. These logging changes are prerequisite to
fixing that mess, so I'll an enthusiast for picking a backend and
getting on with our lives. If you advocate for log4j2, fine with me. I
reported what I thought I'd learned.



>
> I see:
> * incremental build
> * fixing various bugs on dependency plugin (tree doesn't work well
> since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
> old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
> votes. And IMHO dependency:tree is one of the most important when you
> want to debug to dependencies.
> * some jiras we have for core. link
> (https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel)
> says 648 open issues ! And they are some very blockers/majors here.
> * etc...
>
> Regarding logging, move to slf4j and by default add our own slf4j
> implementation based on the current plexus logging (then we can simply
> provide a plugin for users who want to choose an other impl, this
> plugin will simply update users installations).
> Integrators can simply made their own packaging as they do today.
>
>
>
>
>
> 2012/12/16 Benson Margulies <bi...@gmail.com>:
>> Since not much has been heard on the 'pick a logger' question for some
>> time, I'm going to stick my neck out and try to summarize some
>> aspects, in the hopes of discovering how close we are to a consensus.
>>
>> In the following, I use the word 'want' to express *preference*, not
>> non-negotiable demands.
>>
>> We all need: reasonable performance, an acceptable license (i.e.
>> category A or B), a stable, reliable, logger.
>>
>> Various of us want: MDCs, colorization: a package with a community
>> behind it, an avoidance of of EPL, to use our fellow Apache-projects'
>> outputs.
>>
>> We know that: java.util.logging isn't going to give us MDCs or
>> colorization without a great deal of effort. So I'm crossing it off in
>> this email.
>>
>> Now, I'm going to express an opinion based on all the email *I've*
>> seen. I don't claim to be right, but I wonder if people would be
>> willing to follow my logic.
>>
>> Once we eliminate j.u.l from consideration, our choices are logback,
>> log4j 1.x, and log4j 2.x.
>>
>> It seems to me that log4j 2.x is not really ready for us yet, so in
>> this email I'm crossing it off. If we continue to dither for another
>> few months, that might change. If someone disagrees, I'm sure they'll
>> respond.
>>
>> log4j1.x is the tried and true alternative. Colorization, however,
>> would require significant effort. Those of us who don't give a fig
>> about colourization won't be perturbed by this.
>>
>> logback, on the other hand, is very widely adopted, and no one seems
>> to be able to offer any *technical* objection to it. And it gives us
>> colorization out of the box.
>>
>> The objections to logback, then, are cultural, organizational, and/or
>> related to license.
>>
>> In my view, the very broad adoption of logback seems to me to
>> neutralize the concern that it's a one-man-band. While one person
>> projects present certain risks in the abstract, this particular one
>> seems to me not to raise them.
>>
>> In my view, objecting based on EPL is, as I wrote once before, not
>> appropriate. The Maven project erected a barrier to EPL dependencies
>> to respond to cases in which core Maven functionality was forked and
>> EPL-ified, or just proposed to be replaced by EPL code. The situation
>> with logging is simply not analogous. As a project, I don't think we
>> need to anticipate wanting to bring the logging system into our
>> source. Adding a category B logging dependency does not contribute to
>> the 'hollowing out' of Maven.
>>
>> As a Foundation, category B licenses are just as acceptable as
>> category A licenses as dependencies. (I also wonder why this barrier
>> was not specifically set up in terms of 'core code replaced by non-A'
>> instead of 'EPL').
>>
>> If I add this all up, to me it amounts to a test. If some member(s) of
>> this community really, really, want to take log4j 1.x in order to 'use
>> Apache' or 'have a community', I think that those people should be
>> willing to step up and *write the code* to make log4j 1.x
>> feature-equivalent with logback for our purposes. The same logic would
>> apply to j.u.l, though my impression is that there is no practical
>> coding path that gets to equivalence.
>>
>> I trust that this email will inspire response; perhaps it will inspire
>> a response that allows us to detect some consensus.
>>
>> ---------------------------------------------------------------------
>> 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: Logging

[Mark Derricutt <ma...@talios.com>]

Personally I find "-X dependency:tree" -way- more useful.  Half the time 
when I'm trying to track down dependency problems maven itself fails to 
fully resolve dependencies and crashes out the mojo without displaying 
anything useful, so you end up looking though the debug information to 
find which last dep. resolution triggered things to die.

Olivier Lamy wrote:
> votes. And IMHO dependency:tree is one of the most important when you
> want to debug to dependencies.

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

Re: Logging

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

+10000000000

i really think "maven is bad" sentences we sometimes hear doesn't
reference the logging at all so probably not something where time
should be lost

Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2012/12/17 Olivier Lamy <ol...@apache.org>:
> And what about working on real improvements for users ?
>
> I see:
> * incremental build
> * fixing various bugs on dependency plugin (tree doesn't work well
> since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
> old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
> votes. And IMHO dependency:tree is one of the most important when you
> want to debug to dependencies.
> * some jiras we have for core. link
> (https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel)
> says 648 open issues ! And they are some very blockers/majors here.
> * etc...
>
> Regarding logging, move to slf4j and by default add our own slf4j
> implementation based on the current plexus logging (then we can simply
> provide a plugin for users who want to choose an other impl, this
> plugin will simply update users installations).
> Integrators can simply made their own packaging as they do today.
>
>
>
>
>
> 2012/12/16 Benson Margulies <bi...@gmail.com>:
>> Since not much has been heard on the 'pick a logger' question for some
>> time, I'm going to stick my neck out and try to summarize some
>> aspects, in the hopes of discovering how close we are to a consensus.
>>
>> In the following, I use the word 'want' to express *preference*, not
>> non-negotiable demands.
>>
>> We all need: reasonable performance, an acceptable license (i.e.
>> category A or B), a stable, reliable, logger.
>>
>> Various of us want: MDCs, colorization: a package with a community
>> behind it, an avoidance of of EPL, to use our fellow Apache-projects'
>> outputs.
>>
>> We know that: java.util.logging isn't going to give us MDCs or
>> colorization without a great deal of effort. So I'm crossing it off in
>> this email.
>>
>> Now, I'm going to express an opinion based on all the email *I've*
>> seen. I don't claim to be right, but I wonder if people would be
>> willing to follow my logic.
>>
>> Once we eliminate j.u.l from consideration, our choices are logback,
>> log4j 1.x, and log4j 2.x.
>>
>> It seems to me that log4j 2.x is not really ready for us yet, so in
>> this email I'm crossing it off. If we continue to dither for another
>> few months, that might change. If someone disagrees, I'm sure they'll
>> respond.
>>
>> log4j1.x is the tried and true alternative. Colorization, however,
>> would require significant effort. Those of us who don't give a fig
>> about colourization won't be perturbed by this.
>>
>> logback, on the other hand, is very widely adopted, and no one seems
>> to be able to offer any *technical* objection to it. And it gives us
>> colorization out of the box.
>>
>> The objections to logback, then, are cultural, organizational, and/or
>> related to license.
>>
>> In my view, the very broad adoption of logback seems to me to
>> neutralize the concern that it's a one-man-band. While one person
>> projects present certain risks in the abstract, this particular one
>> seems to me not to raise them.
>>
>> In my view, objecting based on EPL is, as I wrote once before, not
>> appropriate. The Maven project erected a barrier to EPL dependencies
>> to respond to cases in which core Maven functionality was forked and
>> EPL-ified, or just proposed to be replaced by EPL code. The situation
>> with logging is simply not analogous. As a project, I don't think we
>> need to anticipate wanting to bring the logging system into our
>> source. Adding a category B logging dependency does not contribute to
>> the 'hollowing out' of Maven.
>>
>> As a Foundation, category B licenses are just as acceptable as
>> category A licenses as dependencies. (I also wonder why this barrier
>> was not specifically set up in terms of 'core code replaced by non-A'
>> instead of 'EPL').
>>
>> If I add this all up, to me it amounts to a test. If some member(s) of
>> this community really, really, want to take log4j 1.x in order to 'use
>> Apache' or 'have a community', I think that those people should be
>> willing to step up and *write the code* to make log4j 1.x
>> feature-equivalent with logback for our purposes. The same logic would
>> apply to j.u.l, though my impression is that there is no practical
>> coding path that gets to equivalence.
>>
>> I trust that this email will inspire response; perhaps it will inspire
>> a response that allows us to detect some consensus.
>>
>> ---------------------------------------------------------------------
>> 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: Logging

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

And what about working on real improvements for users ?

I see:
* incremental build
* fixing various bugs on dependency plugin (tree doesn't work well
since aether: http://jira.codehaus.org/browse/MDEP-392) or this very
old one (https://jira.codehaus.org/browse/MDEP-187) which have 50
votes. And IMHO dependency:tree is one of the most important when you
want to debug to dependencies.
* some jiras we have for core. link
(https://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel)
says 648 open issues ! And they are some very blockers/majors here.
* etc...

Regarding logging, move to slf4j and by default add our own slf4j
implementation based on the current plexus logging (then we can simply
provide a plugin for users who want to choose an other impl, this
plugin will simply update users installations).
Integrators can simply made their own packaging as they do today.





2012/12/16 Benson Margulies <bi...@gmail.com>:
> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how close we are to a consensus.
>
> In the following, I use the word 'want' to express *preference*, not
> non-negotiable demands.
>
> We all need: reasonable performance, an acceptable license (i.e.
> category A or B), a stable, reliable, logger.
>
> Various of us want: MDCs, colorization: a package with a community
> behind it, an avoidance of of EPL, to use our fellow Apache-projects'
> outputs.
>
> We know that: java.util.logging isn't going to give us MDCs or
> colorization without a great deal of effort. So I'm crossing it off in
> this email.
>
> Now, I'm going to express an opinion based on all the email *I've*
> seen. I don't claim to be right, but I wonder if people would be
> willing to follow my logic.
>
> Once we eliminate j.u.l from consideration, our choices are logback,
> log4j 1.x, and log4j 2.x.
>
> It seems to me that log4j 2.x is not really ready for us yet, so in
> this email I'm crossing it off. If we continue to dither for another
> few months, that might change. If someone disagrees, I'm sure they'll
> respond.
>
> log4j1.x is the tried and true alternative. Colorization, however,
> would require significant effort. Those of us who don't give a fig
> about colourization won't be perturbed by this.
>
> logback, on the other hand, is very widely adopted, and no one seems
> to be able to offer any *technical* objection to it. And it gives us
> colorization out of the box.
>
> The objections to logback, then, are cultural, organizational, and/or
> related to license.
>
> In my view, the very broad adoption of logback seems to me to
> neutralize the concern that it's a one-man-band. While one person
> projects present certain risks in the abstract, this particular one
> seems to me not to raise them.
>
> In my view, objecting based on EPL is, as I wrote once before, not
> appropriate. The Maven project erected a barrier to EPL dependencies
> to respond to cases in which core Maven functionality was forked and
> EPL-ified, or just proposed to be replaced by EPL code. The situation
> with logging is simply not analogous. As a project, I don't think we
> need to anticipate wanting to bring the logging system into our
> source. Adding a category B logging dependency does not contribute to
> the 'hollowing out' of Maven.
>
> As a Foundation, category B licenses are just as acceptable as
> category A licenses as dependencies. (I also wonder why this barrier
> was not specifically set up in terms of 'core code replaced by non-A'
> instead of 'EPL').
>
> If I add this all up, to me it amounts to a test. If some member(s) of
> this community really, really, want to take log4j 1.x in order to 'use
> Apache' or 'have a community', I think that those people should be
> willing to step up and *write the code* to make log4j 1.x
> feature-equivalent with logback for our purposes. The same logic would
> apply to j.u.l, though my impression is that there is no practical
> coding path that gets to equivalence.
>
> I trust that this email will inspire response; perhaps it will inspire
> a response that allows us to detect some consensus.
>
> ---------------------------------------------------------------------
> 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: Logging

[Brian Fox <br...@infinity.nu>]

Great summary Benson, I agree with your assessments here.


On Sun, Dec 16, 2012 at 12:16 PM, Benson Margulies <bi...@gmail.com>wrote:

> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how close we are to a consensus.
>
> In the following, I use the word 'want' to express *preference*, not
> non-negotiable demands.
>
> We all need: reasonable performance, an acceptable license (i.e.
> category A or B), a stable, reliable, logger.
>
> Various of us want: MDCs, colorization: a package with a community
> behind it, an avoidance of of EPL, to use our fellow Apache-projects'
> outputs.
>
> We know that: java.util.logging isn't going to give us MDCs or
> colorization without a great deal of effort. So I'm crossing it off in
> this email.
>
> Now, I'm going to express an opinion based on all the email *I've*
> seen. I don't claim to be right, but I wonder if people would be
> willing to follow my logic.
>
> Once we eliminate j.u.l from consideration, our choices are logback,
> log4j 1.x, and log4j 2.x.
>
> It seems to me that log4j 2.x is not really ready for us yet, so in
> this email I'm crossing it off. If we continue to dither for another
> few months, that might change. If someone disagrees, I'm sure they'll
> respond.
>
> log4j1.x is the tried and true alternative. Colorization, however,
> would require significant effort. Those of us who don't give a fig
> about colourization won't be perturbed by this.
>
> logback, on the other hand, is very widely adopted, and no one seems
> to be able to offer any *technical* objection to it. And it gives us
> colorization out of the box.
>
> The objections to logback, then, are cultural, organizational, and/or
> related to license.
>
> In my view, the very broad adoption of logback seems to me to
> neutralize the concern that it's a one-man-band. While one person
> projects present certain risks in the abstract, this particular one
> seems to me not to raise them.
>
> In my view, objecting based on EPL is, as I wrote once before, not
> appropriate. The Maven project erected a barrier to EPL dependencies
> to respond to cases in which core Maven functionality was forked and
> EPL-ified, or just proposed to be replaced by EPL code. The situation
> with logging is simply not analogous. As a project, I don't think we
> need to anticipate wanting to bring the logging system into our
> source. Adding a category B logging dependency does not contribute to
> the 'hollowing out' of Maven.
>
> As a Foundation, category B licenses are just as acceptable as
> category A licenses as dependencies. (I also wonder why this barrier
> was not specifically set up in terms of 'core code replaced by non-A'
> instead of 'EPL').
>
> If I add this all up, to me it amounts to a test. If some member(s) of
> this community really, really, want to take log4j 1.x in order to 'use
> Apache' or 'have a community', I think that those people should be
> willing to step up and *write the code* to make log4j 1.x
> feature-equivalent with logback for our purposes. The same logic would
> apply to j.u.l, though my impression is that there is no practical
> coding path that gets to equivalence.
>
> I trust that this email will inspire response; perhaps it will inspire
> a response that allows us to detect some consensus.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Logging

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

On Sun, Dec 16, 2012 at 12:16 PM, Benson Margulies <bi...@gmail.com>wrote:

> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how close we are to a consensus.
>
> In the following, I use the word 'want' to express *preference*, not
> non-negotiable demands.
>
> We all need: reasonable performance, an acceptable license (i.e.
> category A or B), a stable, reliable, logger.
>
> Various of us want: MDCs, colorization: a package with a community
> behind it, an avoidance of of EPL, to use our fellow Apache-projects'
> outputs.
>
> We know that: java.util.logging isn't going to give us MDCs or
> colorization without a great deal of effort. So I'm crossing it off in
> this email.
>
> Now, I'm going to express an opinion based on all the email *I've*
> seen. I don't claim to be right, but I wonder if people would be
> willing to follow my logic.
>
> Once we eliminate j.u.l from consideration, our choices are logback,
> log4j 1.x, and log4j 2.x.
>
> It seems to me that log4j 2.x is not really ready for us yet, so in
> this email I'm crossing it off. If we continue to dither for another
> few months, that might change. If someone disagrees, I'm sure they'll
> respond.
>
> log4j1.x is the tried and true alternative. Colorization, however,
> would require significant effort. Those of us who don't give a fig
> about colourization won't be perturbed by this.
>

You can do simple color in log4j 1.x with in one Appender class (as opposed
to a Layout) if you consider ANSI escape codes simple) and a dependency on
the JAnsi jar (for Windows). This might not be a purist's implementation,
it's what I do at work.

Gary


> logback, on the other hand, is very widely adopted, and no one seems
> to be able to offer any *technical* objection to it. And it gives us
> colorization out of the box.
>
> The objections to logback, then, are cultural, organizational, and/or
> related to license.
>
> In my view, the very broad adoption of logback seems to me to
> neutralize the concern that it's a one-man-band. While one person
> projects present certain risks in the abstract, this particular one
> seems to me not to raise them.
>
> In my view, objecting based on EPL is, as I wrote once before, not
> appropriate. The Maven project erected a barrier to EPL dependencies
> to respond to cases in which core Maven functionality was forked and
> EPL-ified, or just proposed to be replaced by EPL code. The situation
> with logging is simply not analogous. As a project, I don't think we
> need to anticipate wanting to bring the logging system into our
> source. Adding a category B logging dependency does not contribute to
> the 'hollowing out' of Maven.
>
> As a Foundation, category B licenses are just as acceptable as
> category A licenses as dependencies. (I also wonder why this barrier
> was not specifically set up in terms of 'core code replaced by non-A'
> instead of 'EPL').
>
> If I add this all up, to me it amounts to a test. If some member(s) of
> this community really, really, want to take log4j 1.x in order to 'use
> Apache' or 'have a community', I think that those people should be
> willing to step up and *write the code* to make log4j 1.x
> feature-equivalent with logback for our purposes. The same logic would
> apply to j.u.l, though my impression is that there is no practical
> coding path that gets to equivalence.
>
> I trust that this email will inspire response; perhaps it will inspire
> a response that allows us to detect some consensus.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Logging

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

I was just giving folks time to make their branches and evaluate. For people who felt strongly like Olviier and myself I expect them to make branches and implement something for comparison.

I didn't want to do anymore work on SLF4J Simple but Ceki is going to implement a reset function in the logger so it may still be viable. I figured this time of year there's no dire rush anymore.

On Dec 16, 2012, at 12:16 PM, Benson Margulies <bi...@gmail.com> wrote:

> Since not much has been heard on the 'pick a logger' question for some
> time, I'm going to stick my neck out and try to summarize some
> aspects, in the hopes of discovering how close we are to a consensus.
> 
> In the following, I use the word 'want' to express *preference*, not
> non-negotiable demands.
> 
> We all need: reasonable performance, an acceptable license (i.e.
> category A or B), a stable, reliable, logger.
> 
> Various of us want: MDCs, colorization: a package with a community
> behind it, an avoidance of of EPL, to use our fellow Apache-projects'
> outputs.
> 
> We know that: java.util.logging isn't going to give us MDCs or
> colorization without a great deal of effort. So I'm crossing it off in
> this email.
> 
> Now, I'm going to express an opinion based on all the email *I've*
> seen. I don't claim to be right, but I wonder if people would be
> willing to follow my logic.
> 
> Once we eliminate j.u.l from consideration, our choices are logback,
> log4j 1.x, and log4j 2.x.
> 
> It seems to me that log4j 2.x is not really ready for us yet, so in
> this email I'm crossing it off. If we continue to dither for another
> few months, that might change. If someone disagrees, I'm sure they'll
> respond.
> 
> log4j1.x is the tried and true alternative. Colorization, however,
> would require significant effort. Those of us who don't give a fig
> about colourization won't be perturbed by this.
> 
> logback, on the other hand, is very widely adopted, and no one seems
> to be able to offer any *technical* objection to it. And it gives us
> colorization out of the box.
> 
> The objections to logback, then, are cultural, organizational, and/or
> related to license.
> 
> In my view, the very broad adoption of logback seems to me to
> neutralize the concern that it's a one-man-band. While one person
> projects present certain risks in the abstract, this particular one
> seems to me not to raise them.
> 
> In my view, objecting based on EPL is, as I wrote once before, not
> appropriate. The Maven project erected a barrier to EPL dependencies
> to respond to cases in which core Maven functionality was forked and
> EPL-ified, or just proposed to be replaced by EPL code. The situation
> with logging is simply not analogous. As a project, I don't think we
> need to anticipate wanting to bring the logging system into our
> source. Adding a category B logging dependency does not contribute to
> the 'hollowing out' of Maven.
> 
> As a Foundation, category B licenses are just as acceptable as
> category A licenses as dependencies. (I also wonder why this barrier
> was not specifically set up in terms of 'core code replaced by non-A'
> instead of 'EPL').
> 
> If I add this all up, to me it amounts to a test. If some member(s) of
> this community really, really, want to take log4j 1.x in order to 'use
> Apache' or 'have a community', I think that those people should be
> willing to step up and *write the code* to make log4j 1.x
> feature-equivalent with logback for our purposes. The same logic would
> apply to j.u.l, though my impression is that there is no practical
> coding path that gets to equivalence.
> 
> I trust that this email will inspire response; perhaps it will inspire
> a response that allows us to detect some consensus.
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

A language that doesn’t affect the way you think about programming is not worth knowing. 
 
 -- Alan Perlis

Re: Logging

[Benson Margulies <bi...@gmail.com>]

Since not much has been heard on the 'pick a logger' question for some
time, I'm going to stick my neck out and try to summarize some
aspects, in the hopes of discovering how close we are to a consensus.

In the following, I use the word 'want' to express *preference*, not
non-negotiable demands.

We all need: reasonable performance, an acceptable license (i.e.
category A or B), a stable, reliable, logger.

Various of us want: MDCs, colorization: a package with a community
behind it, an avoidance of of EPL, to use our fellow Apache-projects'
outputs.

We know that: java.util.logging isn't going to give us MDCs or
colorization without a great deal of effort. So I'm crossing it off in
this email.

Now, I'm going to express an opinion based on all the email *I've*
seen. I don't claim to be right, but I wonder if people would be
willing to follow my logic.

Once we eliminate j.u.l from consideration, our choices are logback,
log4j 1.x, and log4j 2.x.

It seems to me that log4j 2.x is not really ready for us yet, so in
this email I'm crossing it off. If we continue to dither for another
few months, that might change. If someone disagrees, I'm sure they'll
respond.

log4j1.x is the tried and true alternative. Colorization, however,
would require significant effort. Those of us who don't give a fig
about colourization won't be perturbed by this.

logback, on the other hand, is very widely adopted, and no one seems
to be able to offer any *technical* objection to it. And it gives us
colorization out of the box.

The objections to logback, then, are cultural, organizational, and/or
related to license.

In my view, the very broad adoption of logback seems to me to
neutralize the concern that it's a one-man-band. While one person
projects present certain risks in the abstract, this particular one
seems to me not to raise them.

In my view, objecting based on EPL is, as I wrote once before, not
appropriate. The Maven project erected a barrier to EPL dependencies
to respond to cases in which core Maven functionality was forked and
EPL-ified, or just proposed to be replaced by EPL code. The situation
with logging is simply not analogous. As a project, I don't think we
need to anticipate wanting to bring the logging system into our
source. Adding a category B logging dependency does not contribute to
the 'hollowing out' of Maven.

As a Foundation, category B licenses are just as acceptable as
category A licenses as dependencies. (I also wonder why this barrier
was not specifically set up in terms of 'core code replaced by non-A'
instead of 'EPL').

If I add this all up, to me it amounts to a test. If some member(s) of
this community really, really, want to take log4j 1.x in order to 'use
Apache' or 'have a community', I think that those people should be
willing to step up and *write the code* to make log4j 1.x
feature-equivalent with logback for our purposes. The same logic would
apply to j.u.l, though my impression is that there is no practical
coding path that gets to equivalence.

I trust that this email will inspire response; perhaps it will inspire
a response that allows us to detect some consensus.

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

Re: Logging

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

On Dec 10, 2012, at 3:46 PM, John Casey <jd...@commonjava.org> wrote:

> On 12/10/12 2:42 PM, Jason van Zyl wrote:
>> It would be the default backend, people would not be using Logback APIs directly.
>> 
>> The one place where it's convenient for use the use the Logback APIs is in the CLI where it's not possible to change the log levels without talking directly to the implementation.
> 
> IMO the CLI isn't usable from an embedding standpoint anyway, so it almost doesn't count (it's almost part of the distribution .zip).
> 

Yup, I was just pointing out that we do have to reach into its pocket to do some things.

>> 
>> On Dec 10, 2012, at 3:40 PM, John Casey <jd...@commonjava.org> wrote:
>> 
>>> Reading through the rest of the thread...is this for the default implementation we'll ship with maven, or are we talking about skipping the slf4j-api abstraction and using logback apis directly?
>>> 
>>> If it's just the default backend, I'm not concerned at all. If we're forcing people to use logback, then to me that's a lot less attractive.
>>> 
>>> On 12/10/12 2:34 PM, John Casey wrote:
>>>> On 12/10/12 2:25 PM, Jason van Zyl wrote:
>>>>> John,
>>>>> 
>>>>> Eight other projects at Apache use Logback.
>>>>> 
>>>>> The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any
>>>>> problems with the EPL. I don't think JBoss would ship a huge product
>>>>> entirely based on EPL if there were a problem.
>>>>> 
>>>>> Oracle also now accepts EPL dependencies in their products.
>>>>> 
>>>>> So what, exactly,  is the potential problem?
>>>> 
>>>> I'm not on the drools team, I was only trying to help them use the Maven
>>>> / Aether APIs. Conan mentioned the EPL-ness of Aether as a potential
>>>> problem for them, and was hoping to use Maven to avoid it until I told
>>>> him that Maven itself is using Aether. His answer was that they would
>>>> work around it by isolating the functionality into a separate module
>>>> with different licensing (or something, I didn't get into the details
>>>> with him). Either he's not clear on the license interactions, or there
>>>> is an actual problem that will propagate these licensing complexities
>>>> out to any GPL project embedding Maven. IANAL.
>>>> 
>>>> I'm only relating a conversation that was specifically dealing with this
>>>> issue.
>>>> 
>>>> Increasingly, my work is with integrating Maven into other tools as
>>>> well. Personally, I'd prefer something that keeps the licensing clean.
>>>> 
>>>> AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses.
>>>> I'm not sure how we deal with this internally, but it's a conversation
>>>> that comes up periodically. I don't claim to know all the ins and outs,
>>>> and I think it's not reasonable for someone outside the projects /
>>>> products themselves to claim they do.
>>>> 
>>>> I think it comes down to: Are the licenses compatible? If not, are we
>>>> forcing people to make a decision about taking on extra licensing
>>>> complexity in order to embed Maven?
>>>> 
>>>>> 
>>>>> On Dec 10, 2012, at 3:14 PM, John Casey <jd...@commonjava.org> wrote:
>>>>> 
>>>>>> On 12/9/12 7:50 PM, Jason van Zyl wrote:
>>>>>>> I think it's time to stop patching SLF4J Simple. I have an
>>>>>>> inefficient fix for the embedding problem, but we're likely to run
>>>>>>> into issues concurrency with parallel builds and who knows what
>>>>>>> else. This will patch/change #5 and many hours of trying to get
>>>>>>> SLF4J Simple to work but I think we're pushing the simple
>>>>>>> implementation beyond its scope. So I'd just like to put in Logback
>>>>>>> and be done with it.
>>>>>>> 
>>>>>>> There are at least three of us opposed to using a new logging
>>>>>>> framework, but I don't think there is anyone against using Logback.
>>>>>>> I honestly don't think there is any rational argument for not using
>>>>>>> Logback,
>>>>>> 
>>>>>> I guess m2e and related third-party projects are the things requiring
>>>>>> these "more evolved" logging options.
>>>>>> 
>>>>>> One rational argument against including logback is other third-party
>>>>>> projects that wish to embed Maven but which have licensing conflicts
>>>>>> with EPL. I had a conversation just the other day with the drools
>>>>>> folks over this WRT Aether, where its EPL license was a potential
>>>>>> problem for them. [1]
>>>>>> 
>>>>>> In considering third-party integration, doesn't it make sense to try
>>>>>> to stay clear of introducing licensing problems? Isn't that rational?
>>>>>> 
>>>>>> [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the
>>>>>> sidebar)
>>>>>> 
>>>>>> 
>>>>>> so after doing all the SLF4J work and making a best effort to use
>>>>>> SLF4J Simple I think it's pointless to pursue that path any longer
>>>>>> and put in Logback.
>>>>>>> 
>>>>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I'm a little bit lost too.
>>>>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl
>>>>>>>> fwk (for
>>>>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>>>>> solved only
>>>>>>>> * by having a fix from slf4j (but it isn't sure that the patch
>>>>>>>> makes sense
>>>>>>>> - to be validated by Ceki)
>>>>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>>>>> I think that everyone's will prefer the first solution if possible
>>>>>>>> but if
>>>>>>>> we cannot we'll have the question to select the impl.
>>>>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>>>>> Like I said in another thread I'll understand if the project decide to
>>>>>>>> choose log4j2 even if it is young because we want to support
>>>>>>>> another ASF
>>>>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>>>>> really good support from its team) but in a general case I would
>>>>>>>> prefer to
>>>>>>>> choose logback which is today the reference logging framework (I
>>>>>>>> that case
>>>>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>>>> 
>>>>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>>>> 
>>>>>>>> Arnaud
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>>>>> perspective on this topic.
>>>>>>>>> 
>>>>>>>>> For this first release I would prefer it to not include any of the
>>>>>>>>> more
>>>>>>>>> advanced slf4j implementations, like a few others have already
>>>>>>>>> also stated.
>>>>>>>>> Using simple would give us a good start on this new path while we
>>>>>>>>> investigate what we and the community want feature wise and then
>>>>>>>>> select an
>>>>>>>>> implementation based on these requirements. However, if
>>>>>>>>> slf4-simple can't
>>>>>>>>> do the job of the old behavior when we might not have that option
>>>>>>>>> unfortunately. Or, possibly we could live with these deficiencies?
>>>>>>>>> I'll
>>>>>>>>> leave that to others working with that to decide.
>>>>>>>>> 
>>>>>>>>> But if we have to decide on a more advanced implementation my
>>>>>>>>> choice would
>>>>>>>>> be logback. My choice is based on two things where one being a past
>>>>>>>>> experience where I developed an audit logging solution based on
>>>>>>>>> logback,
>>>>>>>>> where my research showed that log4j had so many deficiencies when
>>>>>>>>> it came
>>>>>>>>> to more advanced cases. log4j2 might be a different story with
>>>>>>>>> this fixed
>>>>>>>>> though, but I don't see any reason trying something else when
>>>>>>>>> there is
>>>>>>>>> proven option. Secondly, I have good confidence in Ceki and that
>>>>>>>>> he will
>>>>>>>>> help us out should we need that. I'm not saying those working with
>>>>>>>>> log4j2
>>>>>>>>> will not, it's just that I don't know their track record as I know
>>>>>>>>> Ceki's.
>>>>>>>>> 
>>>>>>>>> But to repeat myself, going simple in the first release would be
>>>>>>>>> so much
>>>>>>>>> better. Then we could get our requirements after this first
>>>>>>>>> release and do
>>>>>>>>> a selection based on them rather than just a gut feeling. Although
>>>>>>>>> using
>>>>>>>>> slf4j as the API gives us the technical possibility of switching
>>>>>>>>> impl later
>>>>>>>>> on, I don't think we want that as we can probably expect some
>>>>>>>>> people do
>>>>>>>>> solutions expecting a specific impl (as we've seen in the Sonar
>>>>>>>>> plugin for
>>>>>>>>> example).
>>>>>>>>> 
>>>>>>>>> /Anders
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>>>> 
>>>>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>>>>> Furthermore I'm fine working with an Apache community in case
>>>>>>>>>>>> of any
>>>>>>>>>>>> issue we could have.
>>>>>>>>>>> 
>>>>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>>>>> going,  but I'm firmly opposed
>>>>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> +1
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Kristian
>>>>>>>>>>> 
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> 
>>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>> dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>> <javascript:;>
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> -----
>>>>>>>> Arnaud Héritier
>>>>>>>> http://aheritier.net
>>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>>> Twitter/Skype : aheritier
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Jason
>>>>>>> 
>>>>>>> ----------------------------------------------------------
>>>>>>> Jason van Zyl
>>>>>>> Founder & CTO, Sonatype
>>>>>>> Founder,  Apache Maven
>>>>>>> http://twitter.com/jvanzyl
>>>>>>> ---------------------------------------------------------
>>>>>>> 
>>>>>>> Three people can keep a secret provided two of them are dead.
>>>>>>> 
>>>>>>>  -- Benjamin Franklin
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> John Casey
>>>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>>>> GitHub - http://github.com/jdcasey
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> GitHub - http://github.com/jdcasey
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> Selfish deeds are the shortest path to self destruction.
>> 
>>  -- The Seven Samuari, Akira Kurosawa
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> GitHub - http://github.com/jdcasey
> 
> ---------------------------------------------------------------------
> 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: Logging

[John Casey <jd...@commonjava.org>]

On 12/10/12 2:42 PM, Jason van Zyl wrote:
> It would be the default backend, people would not be using Logback APIs directly.
>
> The one place where it's convenient for use the use the Logback APIs is in the CLI where it's not possible to change the log levels without talking directly to the implementation.

IMO the CLI isn't usable from an embedding standpoint anyway, so it 
almost doesn't count (it's almost part of the distribution .zip).

>
> On Dec 10, 2012, at 3:40 PM, John Casey <jd...@commonjava.org> wrote:
>
>> Reading through the rest of the thread...is this for the default implementation we'll ship with maven, or are we talking about skipping the slf4j-api abstraction and using logback apis directly?
>>
>> If it's just the default backend, I'm not concerned at all. If we're forcing people to use logback, then to me that's a lot less attractive.
>>
>> On 12/10/12 2:34 PM, John Casey wrote:
>>> On 12/10/12 2:25 PM, Jason van Zyl wrote:
>>>> John,
>>>>
>>>> Eight other projects at Apache use Logback.
>>>>
>>>> The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any
>>>> problems with the EPL. I don't think JBoss would ship a huge product
>>>> entirely based on EPL if there were a problem.
>>>>
>>>> Oracle also now accepts EPL dependencies in their products.
>>>>
>>>> So what, exactly,  is the potential problem?
>>>
>>> I'm not on the drools team, I was only trying to help them use the Maven
>>> / Aether APIs. Conan mentioned the EPL-ness of Aether as a potential
>>> problem for them, and was hoping to use Maven to avoid it until I told
>>> him that Maven itself is using Aether. His answer was that they would
>>> work around it by isolating the functionality into a separate module
>>> with different licensing (or something, I didn't get into the details
>>> with him). Either he's not clear on the license interactions, or there
>>> is an actual problem that will propagate these licensing complexities
>>> out to any GPL project embedding Maven. IANAL.
>>>
>>> I'm only relating a conversation that was specifically dealing with this
>>> issue.
>>>
>>> Increasingly, my work is with integrating Maven into other tools as
>>> well. Personally, I'd prefer something that keeps the licensing clean.
>>>
>>> AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses.
>>> I'm not sure how we deal with this internally, but it's a conversation
>>> that comes up periodically. I don't claim to know all the ins and outs,
>>> and I think it's not reasonable for someone outside the projects /
>>> products themselves to claim they do.
>>>
>>> I think it comes down to: Are the licenses compatible? If not, are we
>>> forcing people to make a decision about taking on extra licensing
>>> complexity in order to embed Maven?
>>>
>>>>
>>>> On Dec 10, 2012, at 3:14 PM, John Casey <jd...@commonjava.org> wrote:
>>>>
>>>>> On 12/9/12 7:50 PM, Jason van Zyl wrote:
>>>>>> I think it's time to stop patching SLF4J Simple. I have an
>>>>>> inefficient fix for the embedding problem, but we're likely to run
>>>>>> into issues concurrency with parallel builds and who knows what
>>>>>> else. This will patch/change #5 and many hours of trying to get
>>>>>> SLF4J Simple to work but I think we're pushing the simple
>>>>>> implementation beyond its scope. So I'd just like to put in Logback
>>>>>> and be done with it.
>>>>>>
>>>>>> There are at least three of us opposed to using a new logging
>>>>>> framework, but I don't think there is anyone against using Logback.
>>>>>> I honestly don't think there is any rational argument for not using
>>>>>> Logback,
>>>>>
>>>>> I guess m2e and related third-party projects are the things requiring
>>>>> these "more evolved" logging options.
>>>>>
>>>>> One rational argument against including logback is other third-party
>>>>> projects that wish to embed Maven but which have licensing conflicts
>>>>> with EPL. I had a conversation just the other day with the drools
>>>>> folks over this WRT Aether, where its EPL license was a potential
>>>>> problem for them. [1]
>>>>>
>>>>> In considering third-party integration, doesn't it make sense to try
>>>>> to stay clear of introducing licensing problems? Isn't that rational?
>>>>>
>>>>> [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the
>>>>> sidebar)
>>>>>
>>>>>
>>>>> so after doing all the SLF4J work and making a best effort to use
>>>>> SLF4J Simple I think it's pointless to pursue that path any longer
>>>>> and put in Logback.
>>>>>>
>>>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm a little bit lost too.
>>>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl
>>>>>>> fwk (for
>>>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>>>> solved only
>>>>>>> * by having a fix from slf4j (but it isn't sure that the patch
>>>>>>> makes sense
>>>>>>> - to be validated by Ceki)
>>>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>>>> I think that everyone's will prefer the first solution if possible
>>>>>>> but if
>>>>>>> we cannot we'll have the question to select the impl.
>>>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>>>> Like I said in another thread I'll understand if the project decide to
>>>>>>> choose log4j2 even if it is young because we want to support
>>>>>>> another ASF
>>>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>>>> really good support from its team) but in a general case I would
>>>>>>> prefer to
>>>>>>> choose logback which is today the reference logging framework (I
>>>>>>> that case
>>>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>>>
>>>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>>>
>>>>>>> Arnaud
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>>>> perspective on this topic.
>>>>>>>>
>>>>>>>> For this first release I would prefer it to not include any of the
>>>>>>>> more
>>>>>>>> advanced slf4j implementations, like a few others have already
>>>>>>>> also stated.
>>>>>>>> Using simple would give us a good start on this new path while we
>>>>>>>> investigate what we and the community want feature wise and then
>>>>>>>> select an
>>>>>>>> implementation based on these requirements. However, if
>>>>>>>> slf4-simple can't
>>>>>>>> do the job of the old behavior when we might not have that option
>>>>>>>> unfortunately. Or, possibly we could live with these deficiencies?
>>>>>>>> I'll
>>>>>>>> leave that to others working with that to decide.
>>>>>>>>
>>>>>>>> But if we have to decide on a more advanced implementation my
>>>>>>>> choice would
>>>>>>>> be logback. My choice is based on two things where one being a past
>>>>>>>> experience where I developed an audit logging solution based on
>>>>>>>> logback,
>>>>>>>> where my research showed that log4j had so many deficiencies when
>>>>>>>> it came
>>>>>>>> to more advanced cases. log4j2 might be a different story with
>>>>>>>> this fixed
>>>>>>>> though, but I don't see any reason trying something else when
>>>>>>>> there is
>>>>>>>> proven option. Secondly, I have good confidence in Ceki and that
>>>>>>>> he will
>>>>>>>> help us out should we need that. I'm not saying those working with
>>>>>>>> log4j2
>>>>>>>> will not, it's just that I don't know their track record as I know
>>>>>>>> Ceki's.
>>>>>>>>
>>>>>>>> But to repeat myself, going simple in the first release would be
>>>>>>>> so much
>>>>>>>> better. Then we could get our requirements after this first
>>>>>>>> release and do
>>>>>>>> a selection based on them rather than just a gut feeling. Although
>>>>>>>> using
>>>>>>>> slf4j as the API gives us the technical possibility of switching
>>>>>>>> impl later
>>>>>>>> on, I don't think we want that as we can probably expect some
>>>>>>>> people do
>>>>>>>> solutions expecting a specific impl (as we've seen in the Sonar
>>>>>>>> plugin for
>>>>>>>> example).
>>>>>>>>
>>>>>>>> /Anders
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>>>
>>>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>>>> Furthermore I'm fine working with an Apache community in case
>>>>>>>>>>> of any
>>>>>>>>>>> issue we could have.
>>>>>>>>>>
>>>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>>>> going,  but I'm firmly opposed
>>>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Kristian
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>> <javascript:;>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -----
>>>>>>> Arnaud Héritier
>>>>>>> http://aheritier.net
>>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>>> Twitter/Skype : aheritier
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder & CTO, Sonatype
>>>>>> Founder,  Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>>
>>>>>> Three people can keep a secret provided two of them are dead.
>>>>>>
>>>>>>   -- Benjamin Franklin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> John Casey
>>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>>> GitHub - http://github.com/jdcasey
>>>>
>>>> Thanks,
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> GitHub - http://github.com/jdcasey
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
>   -- The Seven Samuari, Akira Kurosawa
>
>
>
>
>
>


-- 
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey

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

Re: Logging

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

It would be the default backend, people would not be using Logback APIs directly.

The one place where it's convenient for use the use the Logback APIs is in the CLI where it's not possible to change the log levels without talking directly to the implementation.

On Dec 10, 2012, at 3:40 PM, John Casey <jd...@commonjava.org> wrote:

> Reading through the rest of the thread...is this for the default implementation we'll ship with maven, or are we talking about skipping the slf4j-api abstraction and using logback apis directly?
> 
> If it's just the default backend, I'm not concerned at all. If we're forcing people to use logback, then to me that's a lot less attractive.
> 
> On 12/10/12 2:34 PM, John Casey wrote:
>> On 12/10/12 2:25 PM, Jason van Zyl wrote:
>>> John,
>>> 
>>> Eight other projects at Apache use Logback.
>>> 
>>> The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any
>>> problems with the EPL. I don't think JBoss would ship a huge product
>>> entirely based on EPL if there were a problem.
>>> 
>>> Oracle also now accepts EPL dependencies in their products.
>>> 
>>> So what, exactly,  is the potential problem?
>> 
>> I'm not on the drools team, I was only trying to help them use the Maven
>> / Aether APIs. Conan mentioned the EPL-ness of Aether as a potential
>> problem for them, and was hoping to use Maven to avoid it until I told
>> him that Maven itself is using Aether. His answer was that they would
>> work around it by isolating the functionality into a separate module
>> with different licensing (or something, I didn't get into the details
>> with him). Either he's not clear on the license interactions, or there
>> is an actual problem that will propagate these licensing complexities
>> out to any GPL project embedding Maven. IANAL.
>> 
>> I'm only relating a conversation that was specifically dealing with this
>> issue.
>> 
>> Increasingly, my work is with integrating Maven into other tools as
>> well. Personally, I'd prefer something that keeps the licensing clean.
>> 
>> AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses.
>> I'm not sure how we deal with this internally, but it's a conversation
>> that comes up periodically. I don't claim to know all the ins and outs,
>> and I think it's not reasonable for someone outside the projects /
>> products themselves to claim they do.
>> 
>> I think it comes down to: Are the licenses compatible? If not, are we
>> forcing people to make a decision about taking on extra licensing
>> complexity in order to embed Maven?
>> 
>>> 
>>> On Dec 10, 2012, at 3:14 PM, John Casey <jd...@commonjava.org> wrote:
>>> 
>>>> On 12/9/12 7:50 PM, Jason van Zyl wrote:
>>>>> I think it's time to stop patching SLF4J Simple. I have an
>>>>> inefficient fix for the embedding problem, but we're likely to run
>>>>> into issues concurrency with parallel builds and who knows what
>>>>> else. This will patch/change #5 and many hours of trying to get
>>>>> SLF4J Simple to work but I think we're pushing the simple
>>>>> implementation beyond its scope. So I'd just like to put in Logback
>>>>> and be done with it.
>>>>> 
>>>>> There are at least three of us opposed to using a new logging
>>>>> framework, but I don't think there is anyone against using Logback.
>>>>> I honestly don't think there is any rational argument for not using
>>>>> Logback,
>>>> 
>>>> I guess m2e and related third-party projects are the things requiring
>>>> these "more evolved" logging options.
>>>> 
>>>> One rational argument against including logback is other third-party
>>>> projects that wish to embed Maven but which have licensing conflicts
>>>> with EPL. I had a conversation just the other day with the drools
>>>> folks over this WRT Aether, where its EPL license was a potential
>>>> problem for them. [1]
>>>> 
>>>> In considering third-party integration, doesn't it make sense to try
>>>> to stay clear of introducing licensing problems? Isn't that rational?
>>>> 
>>>> [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the
>>>> sidebar)
>>>> 
>>>> 
>>>> so after doing all the SLF4J work and making a best effort to use
>>>> SLF4J Simple I think it's pointless to pursue that path any longer
>>>> and put in Logback.
>>>>> 
>>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> I'm a little bit lost too.
>>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl
>>>>>> fwk (for
>>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>>> solved only
>>>>>> * by having a fix from slf4j (but it isn't sure that the patch
>>>>>> makes sense
>>>>>> - to be validated by Ceki)
>>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>>> I think that everyone's will prefer the first solution if possible
>>>>>> but if
>>>>>> we cannot we'll have the question to select the impl.
>>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>>> Like I said in another thread I'll understand if the project decide to
>>>>>> choose log4j2 even if it is young because we want to support
>>>>>> another ASF
>>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>>> really good support from its team) but in a general case I would
>>>>>> prefer to
>>>>>> choose logback which is today the reference logging framework (I
>>>>>> that case
>>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>> 
>>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>> 
>>>>>> Arnaud
>>>>>> 
>>>>>> 
>>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net>
>>>>>> wrote:
>>>>>> 
>>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>>> perspective on this topic.
>>>>>>> 
>>>>>>> For this first release I would prefer it to not include any of the
>>>>>>> more
>>>>>>> advanced slf4j implementations, like a few others have already
>>>>>>> also stated.
>>>>>>> Using simple would give us a good start on this new path while we
>>>>>>> investigate what we and the community want feature wise and then
>>>>>>> select an
>>>>>>> implementation based on these requirements. However, if
>>>>>>> slf4-simple can't
>>>>>>> do the job of the old behavior when we might not have that option
>>>>>>> unfortunately. Or, possibly we could live with these deficiencies?
>>>>>>> I'll
>>>>>>> leave that to others working with that to decide.
>>>>>>> 
>>>>>>> But if we have to decide on a more advanced implementation my
>>>>>>> choice would
>>>>>>> be logback. My choice is based on two things where one being a past
>>>>>>> experience where I developed an audit logging solution based on
>>>>>>> logback,
>>>>>>> where my research showed that log4j had so many deficiencies when
>>>>>>> it came
>>>>>>> to more advanced cases. log4j2 might be a different story with
>>>>>>> this fixed
>>>>>>> though, but I don't see any reason trying something else when
>>>>>>> there is
>>>>>>> proven option. Secondly, I have good confidence in Ceki and that
>>>>>>> he will
>>>>>>> help us out should we need that. I'm not saying those working with
>>>>>>> log4j2
>>>>>>> will not, it's just that I don't know their track record as I know
>>>>>>> Ceki's.
>>>>>>> 
>>>>>>> But to repeat myself, going simple in the first release would be
>>>>>>> so much
>>>>>>> better. Then we could get our requirements after this first
>>>>>>> release and do
>>>>>>> a selection based on them rather than just a gut feeling. Although
>>>>>>> using
>>>>>>> slf4j as the API gives us the technical possibility of switching
>>>>>>> impl later
>>>>>>> on, I don't think we want that as we can probably expect some
>>>>>>> people do
>>>>>>> solutions expecting a specific impl (as we've seen in the Sonar
>>>>>>> plugin for
>>>>>>> example).
>>>>>>> 
>>>>>>> /Anders
>>>>>>> 
>>>>>>> 
>>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>> 
>>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>> 
>>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>>> Furthermore I'm fine working with an Apache community in case
>>>>>>>>>> of any
>>>>>>>>>> issue we could have.
>>>>>>>>> 
>>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>>> going,  but I'm firmly opposed
>>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> +1
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Kristian
>>>>>>>>> 
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>> dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> <javascript:;>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> -----
>>>>>> Arnaud Héritier
>>>>>> http://aheritier.net
>>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>>> Twitter/Skype : aheritier
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Jason
>>>>> 
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder & CTO, Sonatype
>>>>> Founder,  Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ---------------------------------------------------------
>>>>> 
>>>>> Three people can keep a secret provided two of them are dead.
>>>>> 
>>>>>  -- Benjamin Franklin
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> John Casey
>>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>>> GitHub - http://github.com/jdcasey
>>> 
>>> Thanks,
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> GitHub - http://github.com/jdcasey

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa

Re: Logging

[John Casey <jd...@commonjava.org>]

Reading through the rest of the thread...is this for the default 
implementation we'll ship with maven, or are we talking about skipping 
the slf4j-api abstraction and using logback apis directly?

If it's just the default backend, I'm not concerned at all. If we're 
forcing people to use logback, then to me that's a lot less attractive.

On 12/10/12 2:34 PM, John Casey wrote:
> On 12/10/12 2:25 PM, Jason van Zyl wrote:
>> John,
>>
>> Eight other projects at Apache use Logback.
>>
>> The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any
>> problems with the EPL. I don't think JBoss would ship a huge product
>> entirely based on EPL if there were a problem.
>>
>> Oracle also now accepts EPL dependencies in their products.
>>
>> So what, exactly,  is the potential problem?
>
> I'm not on the drools team, I was only trying to help them use the Maven
> / Aether APIs. Conan mentioned the EPL-ness of Aether as a potential
> problem for them, and was hoping to use Maven to avoid it until I told
> him that Maven itself is using Aether. His answer was that they would
> work around it by isolating the functionality into a separate module
> with different licensing (or something, I didn't get into the details
> with him). Either he's not clear on the license interactions, or there
> is an actual problem that will propagate these licensing complexities
> out to any GPL project embedding Maven. IANAL.
>
> I'm only relating a conversation that was specifically dealing with this
> issue.
>
> Increasingly, my work is with integrating Maven into other tools as
> well. Personally, I'd prefer something that keeps the licensing clean.
>
> AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses.
> I'm not sure how we deal with this internally, but it's a conversation
> that comes up periodically. I don't claim to know all the ins and outs,
> and I think it's not reasonable for someone outside the projects /
> products themselves to claim they do.
>
> I think it comes down to: Are the licenses compatible? If not, are we
> forcing people to make a decision about taking on extra licensing
> complexity in order to embed Maven?
>
>>
>> On Dec 10, 2012, at 3:14 PM, John Casey <jd...@commonjava.org> wrote:
>>
>>> On 12/9/12 7:50 PM, Jason van Zyl wrote:
>>>> I think it's time to stop patching SLF4J Simple. I have an
>>>> inefficient fix for the embedding problem, but we're likely to run
>>>> into issues concurrency with parallel builds and who knows what
>>>> else. This will patch/change #5 and many hours of trying to get
>>>> SLF4J Simple to work but I think we're pushing the simple
>>>> implementation beyond its scope. So I'd just like to put in Logback
>>>> and be done with it.
>>>>
>>>> There are at least three of us opposed to using a new logging
>>>> framework, but I don't think there is anyone against using Logback.
>>>> I honestly don't think there is any rational argument for not using
>>>> Logback,
>>>
>>> I guess m2e and related third-party projects are the things requiring
>>> these "more evolved" logging options.
>>>
>>> One rational argument against including logback is other third-party
>>> projects that wish to embed Maven but which have licensing conflicts
>>> with EPL. I had a conversation just the other day with the drools
>>> folks over this WRT Aether, where its EPL license was a potential
>>> problem for them. [1]
>>>
>>> In considering third-party integration, doesn't it make sense to try
>>> to stay clear of introducing licensing problems? Isn't that rational?
>>>
>>> [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the
>>> sidebar)
>>>
>>>
>>> so after doing all the SLF4J work and making a best effort to use
>>> SLF4J Simple I think it's pointless to pursue that path any longer
>>> and put in Logback.
>>>>
>>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'm a little bit lost too.
>>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl
>>>>> fwk (for
>>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>>> solved only
>>>>> * by having a fix from slf4j (but it isn't sure that the patch
>>>>> makes sense
>>>>> - to be validated by Ceki)
>>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>>> I think that everyone's will prefer the first solution if possible
>>>>> but if
>>>>> we cannot we'll have the question to select the impl.
>>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>>> Like I said in another thread I'll understand if the project decide to
>>>>> choose log4j2 even if it is young because we want to support
>>>>> another ASF
>>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>>> really good support from its team) but in a general case I would
>>>>> prefer to
>>>>> choose logback which is today the reference logging framework (I
>>>>> that case
>>>>> we need to have a PMC vote to accept an external component under EPL
>>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>>
>>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>>
>>>>> Arnaud
>>>>>
>>>>>
>>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net>
>>>>> wrote:
>>>>>
>>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>>> perspective on this topic.
>>>>>>
>>>>>> For this first release I would prefer it to not include any of the
>>>>>> more
>>>>>> advanced slf4j implementations, like a few others have already
>>>>>> also stated.
>>>>>> Using simple would give us a good start on this new path while we
>>>>>> investigate what we and the community want feature wise and then
>>>>>> select an
>>>>>> implementation based on these requirements. However, if
>>>>>> slf4-simple can't
>>>>>> do the job of the old behavior when we might not have that option
>>>>>> unfortunately. Or, possibly we could live with these deficiencies?
>>>>>> I'll
>>>>>> leave that to others working with that to decide.
>>>>>>
>>>>>> But if we have to decide on a more advanced implementation my
>>>>>> choice would
>>>>>> be logback. My choice is based on two things where one being a past
>>>>>> experience where I developed an audit logging solution based on
>>>>>> logback,
>>>>>> where my research showed that log4j had so many deficiencies when
>>>>>> it came
>>>>>> to more advanced cases. log4j2 might be a different story with
>>>>>> this fixed
>>>>>> though, but I don't see any reason trying something else when
>>>>>> there is
>>>>>> proven option. Secondly, I have good confidence in Ceki and that
>>>>>> he will
>>>>>> help us out should we need that. I'm not saying those working with
>>>>>> log4j2
>>>>>> will not, it's just that I don't know their track record as I know
>>>>>> Ceki's.
>>>>>>
>>>>>> But to repeat myself, going simple in the first release would be
>>>>>> so much
>>>>>> better. Then we could get our requirements after this first
>>>>>> release and do
>>>>>> a selection based on them rather than just a gut feeling. Although
>>>>>> using
>>>>>> slf4j as the API gives us the technical possibility of switching
>>>>>> impl later
>>>>>> on, I don't think we want that as we can probably expect some
>>>>>> people do
>>>>>> solutions expecting a specific impl (as we've seen in the Sonar
>>>>>> plugin for
>>>>>> example).
>>>>>>
>>>>>> /Anders
>>>>>>
>>>>>>
>>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>>
>>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>>
>>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>>> Furthermore I'm fine working with an Apache community in case
>>>>>>>>> of any
>>>>>>>>> issue we could have.
>>>>>>>>
>>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>>> going,  but I'm firmly opposed
>>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>>
>>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>>
>>>>>>>> Kristian
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> <javascript:;>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -----
>>>>> Arnaud Héritier
>>>>> http://aheritier.net
>>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>>> Twitter/Skype : aheritier
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder & CTO, Sonatype
>>>> Founder,  Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>> Three people can keep a secret provided two of them are dead.
>>>>
>>>>   -- Benjamin Franklin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> GitHub - http://github.com/jdcasey
>>
>> Thanks,
>>
>> 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
>>
>>
>>
>>
>>
>>
>
>


-- 
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey

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

Re: Logging

[John Casey <jd...@commonjava.org>]

On 12/10/12 2:25 PM, Jason van Zyl wrote:
> John,
>
> Eight other projects at Apache use Logback.
>
> The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems with the EPL. I don't think JBoss would ship a huge product entirely based on EPL if there were a problem.
>
> Oracle also now accepts EPL dependencies in their products.
>
> So what, exactly,  is the potential problem?

I'm not on the drools team, I was only trying to help them use the Maven 
/ Aether APIs. Conan mentioned the EPL-ness of Aether as a potential 
problem for them, and was hoping to use Maven to avoid it until I told 
him that Maven itself is using Aether. His answer was that they would 
work around it by isolating the functionality into a separate module 
with different licensing (or something, I didn't get into the details 
with him). Either he's not clear on the license interactions, or there 
is an actual problem that will propagate these licensing complexities 
out to any GPL project embedding Maven. IANAL.

I'm only relating a conversation that was specifically dealing with this 
issue.

Increasingly, my work is with integrating Maven into other tools as 
well. Personally, I'd prefer something that keeps the licensing clean.

AFAIK, different Red Hat projects have EPL, ASL, LGPL, and GPL licenses. 
I'm not sure how we deal with this internally, but it's a conversation 
that comes up periodically. I don't claim to know all the ins and outs, 
and I think it's not reasonable for someone outside the projects / 
products themselves to claim they do.

I think it comes down to: Are the licenses compatible? If not, are we 
forcing people to make a decision about taking on extra licensing 
complexity in order to embed Maven?

>
> On Dec 10, 2012, at 3:14 PM, John Casey <jd...@commonjava.org> wrote:
>
>> On 12/9/12 7:50 PM, Jason van Zyl wrote:
>>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it.
>>>
>>> There are at least three of us opposed to using a new logging framework, but I don't think there is anyone against using Logback. I honestly don't think there is any rational argument for not using Logback,
>>
>> I guess m2e and related third-party projects are the things requiring these "more evolved" logging options.
>>
>> One rational argument against including logback is other third-party projects that wish to embed Maven but which have licensing conflicts with EPL. I had a conversation just the other day with the drools folks over this WRT Aether, where its EPL license was a potential problem for them. [1]
>>
>> In considering third-party integration, doesn't it make sense to try to stay clear of introducing licensing problems? Isn't that rational?
>>
>> [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the sidebar)
>>
>>
>> so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback.
>>>
>>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>>>
>>>> I'm a little bit lost too.
>>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for
>>>> many - good - reasons) but the last bug discovered by Kristian can be
>>>> solved only
>>>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>>>> - to be validated by Ceki)
>>>> * or by using a more evolved impl like logback (or log4j ...).
>>>> I think that everyone's will prefer the first solution if possible but if
>>>> we cannot we'll have the question to select the impl.
>>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>>> Like I said in another thread I'll understand if the project decide to
>>>> choose log4j2 even if it is young because we want to support another ASF
>>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>>> really good support from its team) but in a general case I would prefer to
>>>> choose logback which is today the reference logging framework (I that case
>>>> we need to have a PMC vote to accept an external component under EPL
>>>> license http://maven.apache.org/developers/dependency-policies ?).
>>>>
>>>> What do we need (for 3.1.0) ? What do we do ?
>>>>
>>>> Arnaud
>>>>
>>>>
>>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>>>
>>>>> Not sure where to get into this thread, but I'd just like to add my
>>>>> perspective on this topic.
>>>>>
>>>>> For this first release I would prefer it to not include any of the more
>>>>> advanced slf4j implementations, like a few others have already also stated.
>>>>> Using simple would give us a good start on this new path while we
>>>>> investigate what we and the community want feature wise and then select an
>>>>> implementation based on these requirements. However, if slf4-simple can't
>>>>> do the job of the old behavior when we might not have that option
>>>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>>>> leave that to others working with that to decide.
>>>>>
>>>>> But if we have to decide on a more advanced implementation my choice would
>>>>> be logback. My choice is based on two things where one being a past
>>>>> experience where I developed an audit logging solution based on logback,
>>>>> where my research showed that log4j had so many deficiencies when it came
>>>>> to more advanced cases. log4j2 might be a different story with this fixed
>>>>> though, but I don't see any reason trying something else when there is
>>>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>>>> help us out should we need that. I'm not saying those working with log4j2
>>>>> will not, it's just that I don't know their track record as I know Ceki's.
>>>>>
>>>>> But to repeat myself, going simple in the first release would be so much
>>>>> better. Then we could get our requirements after this first release and do
>>>>> a selection based on them rather than just a gut feeling. Although using
>>>>> slf4j as the API gives us the technical possibility of switching impl later
>>>>> on, I don't think we want that as we can probably expect some people do
>>>>> solutions expecting a specific impl (as we've seen in the Sonar plugin for
>>>>> example).
>>>>>
>>>>> /Anders
>>>>>
>>>>>
>>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com> wrote:
>>>>>
>>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>>>
>>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>>> Perso I'm fine using log4j2.
>>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>>>> issue we could have.
>>>>>>>
>>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>>> going,  but I'm firmly opposed
>>>>>>> to including a brand new logging framework as default in m3.
>>>>>>>
>>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>>> Kristian
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> <javascript:;>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -----
>>>> Arnaud Héritier
>>>> http://aheritier.net
>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>> Twitter/Skype : aheritier
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> Three people can keep a secret provided two of them are dead.
>>>
>>>   -- Benjamin Franklin
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> GitHub - http://github.com/jdcasey
>
> Thanks,
>
> 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
>
>
>
>
>
>


-- 
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey

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

Re: Logging

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

John,

Eight other projects at Apache use Logback.

The whole of JBoss Tooling is EPL so Redhat doesn't appear to have any problems with the EPL. I don't think JBoss would ship a huge product entirely based on EPL if there were a problem. 

Oracle also now accepts EPL dependencies in their products.

So what, exactly,  is the potential problem? 

On Dec 10, 2012, at 3:14 PM, John Casey <jd...@commonjava.org> wrote:

> On 12/9/12 7:50 PM, Jason van Zyl wrote:
>> I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it.
>> 
>> There are at least three of us opposed to using a new logging framework, but I don't think there is anyone against using Logback. I honestly don't think there is any rational argument for not using Logback,
> 
> I guess m2e and related third-party projects are the things requiring these "more evolved" logging options.
> 
> One rational argument against including logback is other third-party projects that wish to embed Maven but which have licensing conflicts with EPL. I had a conversation just the other day with the drools folks over this WRT Aether, where its EPL license was a potential problem for them. [1]
> 
> In considering third-party integration, doesn't it make sense to try to stay clear of introducing licensing problems? Isn't that rational?
> 
> [1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the sidebar)
> 
> 
> so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback.
>> 
>> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>> 
>>> I'm a little bit lost too.
>>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for
>>> many - good - reasons) but the last bug discovered by Kristian can be
>>> solved only
>>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>>> - to be validated by Ceki)
>>> * or by using a more evolved impl like logback (or log4j ...).
>>> I think that everyone's will prefer the first solution if possible but if
>>> we cannot we'll have the question to select the impl.
>>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>>> Like I said in another thread I'll understand if the project decide to
>>> choose log4j2 even if it is young because we want to support another ASF
>>> initiative (And I'm sure we won't have to regret it, and we'll have a
>>> really good support from its team) but in a general case I would prefer to
>>> choose logback which is today the reference logging framework (I that case
>>> we need to have a PMC vote to accept an external component under EPL
>>> license http://maven.apache.org/developers/dependency-policies ?).
>>> 
>>> What do we need (for 3.1.0) ? What do we do ?
>>> 
>>> Arnaud
>>> 
>>> 
>>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>> 
>>>> Not sure where to get into this thread, but I'd just like to add my
>>>> perspective on this topic.
>>>> 
>>>> For this first release I would prefer it to not include any of the more
>>>> advanced slf4j implementations, like a few others have already also stated.
>>>> Using simple would give us a good start on this new path while we
>>>> investigate what we and the community want feature wise and then select an
>>>> implementation based on these requirements. However, if slf4-simple can't
>>>> do the job of the old behavior when we might not have that option
>>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>>> leave that to others working with that to decide.
>>>> 
>>>> But if we have to decide on a more advanced implementation my choice would
>>>> be logback. My choice is based on two things where one being a past
>>>> experience where I developed an audit logging solution based on logback,
>>>> where my research showed that log4j had so many deficiencies when it came
>>>> to more advanced cases. log4j2 might be a different story with this fixed
>>>> though, but I don't see any reason trying something else when there is
>>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>>> help us out should we need that. I'm not saying those working with log4j2
>>>> will not, it's just that I don't know their track record as I know Ceki's.
>>>> 
>>>> But to repeat myself, going simple in the first release would be so much
>>>> better. Then we could get our requirements after this first release and do
>>>> a selection based on them rather than just a gut feeling. Although using
>>>> slf4j as the API gives us the technical possibility of switching impl later
>>>> on, I don't think we want that as we can probably expect some people do
>>>> solutions expecting a specific impl (as we've seen in the Sonar plugin for
>>>> example).
>>>> 
>>>> /Anders
>>>> 
>>>> 
>>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com> wrote:
>>>> 
>>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>> 
>>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>>> Perso I'm fine using log4j2.
>>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>>> issue we could have.
>>>>>> 
>>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>>> going,  but I'm firmly opposed
>>>>>> to including a brand new logging framework as default in m3.
>>>>>> 
>>>>>> 
>>>>> +1
>>>>> 
>>>>> 
>>>>>> Kristian
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> <javascript:;>
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> -----
>>> Arnaud Héritier
>>> http://aheritier.net
>>> Mail/GTalk: aheritier AT gmail DOT com
>>> Twitter/Skype : aheritier
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> Three people can keep a secret provided two of them are dead.
>> 
>>  -- Benjamin Franklin
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> GitHub - http://github.com/jdcasey

Thanks,

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

[John Casey <jd...@commonjava.org>]

On 12/9/12 7:50 PM, Jason van Zyl wrote:
> I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it.
>
> There are at least three of us opposed to using a new logging framework, but I don't think there is anyone against using Logback. I honestly don't think there is any rational argument for not using Logback,

I guess m2e and related third-party projects are the things requiring 
these "more evolved" logging options.

One rational argument against including logback is other third-party 
projects that wish to embed Maven but which have licensing conflicts 
with EPL. I had a conversation just the other day with the drools folks 
over this WRT Aether, where its EPL license was a potential problem for 
them. [1]

In considering third-party integration, doesn't it make sense to try to 
stay clear of introducing licensing problems? Isn't that rational?

[1] http://en.wikipedia.org/wiki/Eclipse_Public_License (see the sidebar)


so after doing all the SLF4J work and making a best effort to use SLF4J 
Simple I think it's pointless to pursue that path any longer and put in 
Logback.
>
> On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:
>
>> I'm a little bit lost too.
>> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for
>> many - good - reasons) but the last bug discovered by Kristian can be
>> solved only
>> * by having a fix from slf4j (but it isn't sure that the patch makes sense
>> - to be validated by Ceki)
>> * or by using a more evolved impl like logback (or log4j ...).
>> I think that everyone's will prefer the first solution if possible but if
>> we cannot we'll have the question to select the impl.
>> Do we need to vote ? Is there really a question logback vs log4j(2) ?
>> Like I said in another thread I'll understand if the project decide to
>> choose log4j2 even if it is young because we want to support another ASF
>> initiative (And I'm sure we won't have to regret it, and we'll have a
>> really good support from its team) but in a general case I would prefer to
>> choose logback which is today the reference logging framework (I that case
>> we need to have a PMC vote to accept an external component under EPL
>> license http://maven.apache.org/developers/dependency-policies ?).
>>
>> What do we need (for 3.1.0) ? What do we do ?
>>
>> Arnaud
>>
>>
>> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
>>
>>> Not sure where to get into this thread, but I'd just like to add my
>>> perspective on this topic.
>>>
>>> For this first release I would prefer it to not include any of the more
>>> advanced slf4j implementations, like a few others have already also stated.
>>> Using simple would give us a good start on this new path while we
>>> investigate what we and the community want feature wise and then select an
>>> implementation based on these requirements. However, if slf4-simple can't
>>> do the job of the old behavior when we might not have that option
>>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>>> leave that to others working with that to decide.
>>>
>>> But if we have to decide on a more advanced implementation my choice would
>>> be logback. My choice is based on two things where one being a past
>>> experience where I developed an audit logging solution based on logback,
>>> where my research showed that log4j had so many deficiencies when it came
>>> to more advanced cases. log4j2 might be a different story with this fixed
>>> though, but I don't see any reason trying something else when there is
>>> proven option. Secondly, I have good confidence in Ceki and that he will
>>> help us out should we need that. I'm not saying those working with log4j2
>>> will not, it's just that I don't know their track record as I know Ceki's.
>>>
>>> But to repeat myself, going simple in the first release would be so much
>>> better. Then we could get our requirements after this first release and do
>>> a selection based on them rather than just a gut feeling. Although using
>>> slf4j as the API gives us the technical possibility of switching impl later
>>> on, I don't think we want that as we can probably expect some people do
>>> solutions expecting a specific impl (as we've seen in the Sonar plugin for
>>> example).
>>>
>>> /Anders
>>>
>>>
>>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>>>
>>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>>> Perso I'm fine using log4j2.
>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>>> issue we could have.
>>>>>
>>>>> I'm not entirely sure I follow where this discussion is actually
>>>>> going,  but I'm firmly opposed
>>>>> to including a brand new logging framework as default in m3.
>>>>>
>>>>>
>>>> +1
>>>>
>>>>
>>>>> Kristian
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> <javascript:;>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> -----
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gmail DOT com
>> Twitter/Skype : aheritier
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Three people can keep a secret provided two of them are dead.
>
>   -- Benjamin Franklin
>
>
>
>
>
>


-- 
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey

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

Re: Logging

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

I think it's time to stop patching SLF4J Simple. I have an inefficient fix for the embedding problem, but we're likely to run into issues concurrency with parallel builds and who knows what else. This will patch/change #5 and many hours of trying to get SLF4J Simple to work but I think we're pushing the simple implementation beyond its scope. So I'd just like to put in Logback and be done with it. 

There are at least three of us opposed to using a new logging framework, but I don't think there is anyone against using Logback. I honestly don't think there is any rational argument for not using Logback,  so after doing all the SLF4J work and making a best effort to use SLF4J Simple I think it's pointless to pursue that path any longer and put in Logback.

On Dec 9, 2012, at 5:45 PM, Arnaud Héritier <ah...@gmail.com> wrote:

> I'm a little bit lost too.
> Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for
> many - good - reasons) but the last bug discovered by Kristian can be
> solved only
> * by having a fix from slf4j (but it isn't sure that the patch makes sense
> - to be validated by Ceki)
> * or by using a more evolved impl like logback (or log4j ...).
> I think that everyone's will prefer the first solution if possible but if
> we cannot we'll have the question to select the impl.
> Do we need to vote ? Is there really a question logback vs log4j(2) ?
> Like I said in another thread I'll understand if the project decide to
> choose log4j2 even if it is young because we want to support another ASF
> initiative (And I'm sure we won't have to regret it, and we'll have a
> really good support from its team) but in a general case I would prefer to
> choose logback which is today the reference logging framework (I that case
> we need to have a PMC vote to accept an external component under EPL
> license http://maven.apache.org/developers/dependency-policies ?).
> 
> What do we need (for 3.1.0) ? What do we do ?
> 
> Arnaud
> 
> 
> On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:
> 
>> Not sure where to get into this thread, but I'd just like to add my
>> perspective on this topic.
>> 
>> For this first release I would prefer it to not include any of the more
>> advanced slf4j implementations, like a few others have already also stated.
>> Using simple would give us a good start on this new path while we
>> investigate what we and the community want feature wise and then select an
>> implementation based on these requirements. However, if slf4-simple can't
>> do the job of the old behavior when we might not have that option
>> unfortunately. Or, possibly we could live with these deficiencies? I'll
>> leave that to others working with that to decide.
>> 
>> But if we have to decide on a more advanced implementation my choice would
>> be logback. My choice is based on two things where one being a past
>> experience where I developed an audit logging solution based on logback,
>> where my research showed that log4j had so many deficiencies when it came
>> to more advanced cases. log4j2 might be a different story with this fixed
>> though, but I don't see any reason trying something else when there is
>> proven option. Secondly, I have good confidence in Ceki and that he will
>> help us out should we need that. I'm not saying those working with log4j2
>> will not, it's just that I don't know their track record as I know Ceki's.
>> 
>> But to repeat myself, going simple in the first release would be so much
>> better. Then we could get our requirements after this first release and do
>> a selection based on them rather than just a gut feeling. Although using
>> slf4j as the API gives us the technical possibility of switching impl later
>> on, I don't think we want that as we can probably expect some people do
>> solutions expecting a specific impl (as we've seen in the Sonar plugin for
>> example).
>> 
>> /Anders
>> 
>> 
>> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>> 
>>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>> 
>>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>>> Perso I'm fine using log4j2.
>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>> Furthermore I'm fine working with an Apache community in case of any
>>>>> issue we could have.
>>>> 
>>>> I'm not entirely sure I follow where this discussion is actually
>>>> going,  but I'm firmly opposed
>>>> to including a brand new logging framework as default in m3.
>>>> 
>>>> 
>>> +1
>>> 
>>> 
>>>> Kristian
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> <javascript:;>
>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin

Re: Logging

[Arnaud Héritier <ah...@gmail.com>]

I'm a little bit lost too.
Thus for now in 3.1.0 we didn't want to provide a new logging impl fwk (for
many - good - reasons) but the last bug discovered by Kristian can be
solved only
* by having a fix from slf4j (but it isn't sure that the patch makes sense
- to be validated by Ceki)
* or by using a more evolved impl like logback (or log4j ...).
I think that everyone's will prefer the first solution if possible but if
we cannot we'll have the question to select the impl.
Do we need to vote ? Is there really a question logback vs log4j(2) ?
Like I said in another thread I'll understand if the project decide to
choose log4j2 even if it is young because we want to support another ASF
initiative (And I'm sure we won't have to regret it, and we'll have a
really good support from its team) but in a general case I would prefer to
choose logback which is today the reference logging framework (I that case
we need to have a PMC vote to accept an external component under EPL
license http://maven.apache.org/developers/dependency-policies ?).

What do we need (for 3.1.0) ? What do we do ?

Arnaud


On Sun, Dec 9, 2012 at 10:53 PM, Anders Hammar <an...@hammar.net> wrote:

> Not sure where to get into this thread, but I'd just like to add my
> perspective on this topic.
>
> For this first release I would prefer it to not include any of the more
> advanced slf4j implementations, like a few others have already also stated.
> Using simple would give us a good start on this new path while we
> investigate what we and the community want feature wise and then select an
> implementation based on these requirements. However, if slf4-simple can't
> do the job of the old behavior when we might not have that option
> unfortunately. Or, possibly we could live with these deficiencies? I'll
> leave that to others working with that to decide.
>
> But if we have to decide on a more advanced implementation my choice would
> be logback. My choice is based on two things where one being a past
> experience where I developed an audit logging solution based on logback,
> where my research showed that log4j had so many deficiencies when it came
> to more advanced cases. log4j2 might be a different story with this fixed
> though, but I don't see any reason trying something else when there is
> proven option. Secondly, I have good confidence in Ceki and that he will
> help us out should we need that. I'm not saying those working with log4j2
> will not, it's just that I don't know their track record as I know Ceki's.
>
> But to repeat myself, going simple in the first release would be so much
> better. Then we could get our requirements after this first release and do
> a selection based on them rather than just a gut feeling. Although using
> slf4j as the API gives us the technical possibility of switching impl later
> on, I don't think we want that as we can probably expect some people do
> solutions expecting a specific impl (as we've seen in the Sonar plugin for
> example).
>
> /Anders
>
>
> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On Sunday, 9 December 2012, Kristian Rosenvold wrote:
> >
> > > 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
> > > > Perso I'm fine using log4j2.
> > > > I use the branch I pushed for some weeks now and I'm happy.
> > > > Log4j2 has quickly added a feature I needed and release it.
> > > > Furthermore I'm fine working with an Apache community in case of any
> > > > issue we could have.
> > >
> > > I'm not entirely sure I follow where this discussion is actually
> > > going,  but I'm firmly opposed
> > > to including a brand new logging framework as default in m3.
> > >
> > >
> > +1
> >
> >
> > > Kristian
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > >
> > >
> >
>



-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Logging

[Jeff Jensen <jj...@apache.org>]

On Sun, Dec 9, 2012 at 6:51 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>
> > 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
> > > Perso I'm fine using log4j2.
> > > I use the branch I pushed for some weeks now and I'm happy.
> > > Log4j2 has quickly added a feature I needed and release it.
> > > Furthermore I'm fine working with an Apache community in case of any
> > > issue we could have.
> >
> > I'm not entirely sure I follow where this discussion is actually
> > going,  but I'm firmly opposed
> > to including a brand new logging framework as default in m3.
> >
> >
> +1
>

+1
I also prefer Logback if sfl4j-simple doesn't have enough features.

Re: Logging

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

Jason,

I fully appreciate that we've reach the end of what slf4j-simple can, and
should, do. I'm just saying that I would have preferred us to use
slf4j-simple for the first release. But you, and a few others, are doing
the work and should decide. I'm just expression a by-stander's thoughts.

However, I would like to suggest the option of releasing with slf4j-simple
and one, or two, known limitations (the bug(s) found with embedded). I
don't have the insight to tell if it's possible but let those of you
investigating do the decision. I'm thinking that in embedded scenarios the
host might already be using a different implementation (like m2e is) so it
might not be a problem.

/Anders


On Sun, Dec 9, 2012 at 11:30 PM, Jason van Zyl <ja...@tesla.io> wrote:

> Anders,
>
> My take is that this will be the 5th change that I've asked for to get the
> SLF4J Simple implementation to work. Initially I had your position and I
> tried to keep it as simple as possible the provide the same behaviour, but
> for embedded environments and concurrent operations I think we're just
> going to run into more of the same. We can continue patching the simple
> implementation and make it do things it wasn't designed to or just switch
> to Logback. I think I gave it a best effort but I don't want to patch SLF4J
> Simple anymore.
>
> On Dec 9, 2012, at 4:53 PM, Anders Hammar <an...@hammar.net> wrote:
>
> > Not sure where to get into this thread, but I'd just like to add my
> > perspective on this topic.
> >
> > For this first release I would prefer it to not include any of the more
> > advanced slf4j implementations, like a few others have already also
> stated.
> > Using simple would give us a good start on this new path while we
> > investigate what we and the community want feature wise and then select
> an
> > implementation based on these requirements. However, if slf4-simple can't
> > do the job of the old behavior when we might not have that option
> > unfortunately. Or, possibly we could live with these deficiencies? I'll
> > leave that to others working with that to decide.
> >
> > But if we have to decide on a more advanced implementation my choice
> would
> > be logback. My choice is based on two things where one being a past
> > experience where I developed an audit logging solution based on logback,
> > where my research showed that log4j had so many deficiencies when it came
> > to more advanced cases. log4j2 might be a different story with this fixed
> > though, but I don't see any reason trying something else when there is
> > proven option. Secondly, I have good confidence in Ceki and that he will
> > help us out should we need that. I'm not saying those working with log4j2
> > will not, it's just that I don't know their track record as I know
> Ceki's.
> >
> > But to repeat myself, going simple in the first release would be so much
> > better. Then we could get our requirements after this first release and
> do
> > a selection based on them rather than just a gut feeling. Although using
> > slf4j as the API gives us the technical possibility of switching impl
> later
> > on, I don't think we want that as we can probably expect some people do
> > solutions expecting a specific impl (as we've seen in the Sonar plugin
> for
> > example).
> >
> > /Anders
> >
> >
> > On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
> >>
> >>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
> >>>> Perso I'm fine using log4j2.
> >>>> I use the branch I pushed for some weeks now and I'm happy.
> >>>> Log4j2 has quickly added a feature I needed and release it.
> >>>> Furthermore I'm fine working with an Apache community in case of any
> >>>> issue we could have.
> >>>
> >>> I'm not entirely sure I follow where this discussion is actually
> >>> going,  but I'm firmly opposed
> >>> to including a brand new logging framework as default in m3.
> >>>
> >>>
> >> +1
> >>
> >>
> >>> Kristian
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >>>
> >>>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
>   -- Jacques Ellul, The Technological Society
>
>
>
>
>
>

Re: Logging

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

Anders,

My take is that this will be the 5th change that I've asked for to get the SLF4J Simple implementation to work. Initially I had your position and I tried to keep it as simple as possible the provide the same behaviour, but for embedded environments and concurrent operations I think we're just going to run into more of the same. We can continue patching the simple implementation and make it do things it wasn't designed to or just switch to Logback. I think I gave it a best effort but I don't want to patch SLF4J Simple anymore.

On Dec 9, 2012, at 4:53 PM, Anders Hammar <an...@hammar.net> wrote:

> Not sure where to get into this thread, but I'd just like to add my
> perspective on this topic.
> 
> For this first release I would prefer it to not include any of the more
> advanced slf4j implementations, like a few others have already also stated.
> Using simple would give us a good start on this new path while we
> investigate what we and the community want feature wise and then select an
> implementation based on these requirements. However, if slf4-simple can't
> do the job of the old behavior when we might not have that option
> unfortunately. Or, possibly we could live with these deficiencies? I'll
> leave that to others working with that to decide.
> 
> But if we have to decide on a more advanced implementation my choice would
> be logback. My choice is based on two things where one being a past
> experience where I developed an audit logging solution based on logback,
> where my research showed that log4j had so many deficiencies when it came
> to more advanced cases. log4j2 might be a different story with this fixed
> though, but I don't see any reason trying something else when there is
> proven option. Secondly, I have good confidence in Ceki and that he will
> help us out should we need that. I'm not saying those working with log4j2
> will not, it's just that I don't know their track record as I know Ceki's.
> 
> But to repeat myself, going simple in the first release would be so much
> better. Then we could get our requirements after this first release and do
> a selection based on them rather than just a gut feeling. Although using
> slf4j as the API gives us the technical possibility of switching impl later
> on, I don't think we want that as we can probably expect some people do
> solutions expecting a specific impl (as we've seen in the Sonar plugin for
> example).
> 
> /Anders
> 
> 
> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> 
>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>> 
>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>> Perso I'm fine using log4j2.
>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>> Log4j2 has quickly added a feature I needed and release it.
>>>> Furthermore I'm fine working with an Apache community in case of any
>>>> issue we could have.
>>> 
>>> I'm not entirely sure I follow where this discussion is actually
>>> going,  but I'm firmly opposed
>>> to including a brand new logging framework as default in m3.
>>> 
>>> 
>> +1
>> 
>> 
>>> Kristian
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>> 
>>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society

Re: Logging

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

Fwiw, once maven anoints a logging framework, it will be near
impossible to switch. IMO that is.

Gary

On Dec 9, 2012, at 16:54, Anders Hammar <an...@hammar.net> wrote:

> Not sure where to get into this thread, but I'd just like to add my
> perspective on this topic.
>
> For this first release I would prefer it to not include any of the more
> advanced slf4j implementations, like a few others have already also stated.
> Using simple would give us a good start on this new path while we
> investigate what we and the community want feature wise and then select an
> implementation based on these requirements. However, if slf4-simple can't
> do the job of the old behavior when we might not have that option
> unfortunately. Or, possibly we could live with these deficiencies? I'll
> leave that to others working with that to decide.
>
> But if we have to decide on a more advanced implementation my choice would
> be logback. My choice is based on two things where one being a past
> experience where I developed an audit logging solution based on logback,
> where my research showed that log4j had so many deficiencies when it came
> to more advanced cases. log4j2 might be a different story with this fixed
> though, but I don't see any reason trying something else when there is
> proven option. Secondly, I have good confidence in Ceki and that he will
> help us out should we need that. I'm not saying those working with log4j2
> will not, it's just that I don't know their track record as I know Ceki's.
>
> But to repeat myself, going simple in the first release would be so much
> better. Then we could get our requirements after this first release and do
> a selection based on them rather than just a gut feeling. Although using
> slf4j as the API gives us the technical possibility of switching impl later
> on, I don't think we want that as we can probably expect some people do
> solutions expecting a specific impl (as we've seen in the Sonar plugin for
> example).
>
> /Anders
>
>
> On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>>
>>> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
>>>> Perso I'm fine using log4j2.
>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>> Log4j2 has quickly added a feature I needed and release it.
>>>> Furthermore I'm fine working with an Apache community in case of any
>>>> issue we could have.
>>>
>>> I'm not entirely sure I follow where this discussion is actually
>>> going,  but I'm firmly opposed
>>> to including a brand new logging framework as default in m3.
>>>
>>>
>> +1
>>
>>
>>> Kristian
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>>>
>>>
>>

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

Re: Logging

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

Not sure where to get into this thread, but I'd just like to add my
perspective on this topic.

For this first release I would prefer it to not include any of the more
advanced slf4j implementations, like a few others have already also stated.
Using simple would give us a good start on this new path while we
investigate what we and the community want feature wise and then select an
implementation based on these requirements. However, if slf4-simple can't
do the job of the old behavior when we might not have that option
unfortunately. Or, possibly we could live with these deficiencies? I'll
leave that to others working with that to decide.

But if we have to decide on a more advanced implementation my choice would
be logback. My choice is based on two things where one being a past
experience where I developed an audit logging solution based on logback,
where my research showed that log4j had so many deficiencies when it came
to more advanced cases. log4j2 might be a different story with this fixed
though, but I don't see any reason trying something else when there is
proven option. Secondly, I have good confidence in Ceki and that he will
help us out should we need that. I'm not saying those working with log4j2
will not, it's just that I don't know their track record as I know Ceki's.

But to repeat myself, going simple in the first release would be so much
better. Then we could get our requirements after this first release and do
a selection based on them rather than just a gut feeling. Although using
slf4j as the API gives us the technical possibility of switching impl later
on, I don't think we want that as we can probably expect some people do
solutions expecting a specific impl (as we've seen in the Sonar plugin for
example).

/Anders


On Sun, Dec 9, 2012 at 1:51 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On Sunday, 9 December 2012, Kristian Rosenvold wrote:
>
> > 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
> > > Perso I'm fine using log4j2.
> > > I use the branch I pushed for some weeks now and I'm happy.
> > > Log4j2 has quickly added a feature I needed and release it.
> > > Furthermore I'm fine working with an Apache community in case of any
> > > issue we could have.
> >
> > I'm not entirely sure I follow where this discussion is actually
> > going,  but I'm firmly opposed
> > to including a brand new logging framework as default in m3.
> >
> >
> +1
>
>
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >
> >
>

Re: Logging

[Stephen Connolly <st...@gmail.com>]

On Sunday, 9 December 2012, Kristian Rosenvold wrote:

> 2012/12/9 Olivier Lamy <olamy@apache.org <javascript:;>>:
> > Perso I'm fine using log4j2.
> > I use the branch I pushed for some weeks now and I'm happy.
> > Log4j2 has quickly added a feature I needed and release it.
> > Furthermore I'm fine working with an Apache community in case of any
> > issue we could have.
>
> I'm not entirely sure I follow where this discussion is actually
> going,  but I'm firmly opposed
> to including a brand new logging framework as default in m3.
>
>
+1


> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

Re: Logging

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

Are you referring to the Simple SLF4J fix or the Logback branch?

I have only run it locally as the CI instance looks borked at the moment?

On Dec 9, 2012, at 5:52 AM, Kristian Rosenvold <kr...@gmail.com> wrote:

> 2012/12/9 Olivier Lamy <ol...@apache.org>:
>> Perso I'm fine using log4j2.
>> I use the branch I pushed for some weeks now and I'm happy.
>> Log4j2 has quickly added a feature I needed and release it.
>> Furthermore I'm fine working with an Apache community in case of any
>> issue we could have.
> 
> I'm not entirely sure I follow where this discussion is actually
> going,  but I'm firmly opposed
> to including a brand new logging framework as default in m3.
> 
> Kristian
> 
> ---------------------------------------------------------------------
> 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: Logging

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

The changes have only been in the simple logger implementation, not the api itself.

On Dec 10, 2012, at 4:06 AM, Mark Struberg <st...@yahoo.de> wrote:

> To be honest. Slf4J is really mature. The fact that we need some 'special treatment' for maven worries me.
> Are we are trying to do things with slf4j-simple it never was intended for? Again: I think sjf4j is really mature, so I guess the error is on our side.
> And you also mentioned that Ceki did special changes in slf4j _itself_ and not only the simple logger? That worries me even more, what changes have that been?
> 
> 
> LieGrue,
> strub
> 
> 
> 
> ----- Original Message -----
>> From: Jason van Zyl <ja...@tesla.io>
>> To: Maven Developers List <de...@maven.apache.org>
>> Cc: 
>> Sent: Monday, December 10, 2012 8:33 AM
>> Subject: Re: Logging
>> 
>> 
>> On Dec 10, 2012, at 2:11 AM, Hervé BOUTEMY <he...@free.fr> wrote:
>> 
>>> trying to be concise and neutral
>>> 
>>> 1. because slf4j-api is well known, it has lots of back-ends, that will 
>>> provide powerfull configuration techniques for filtering, display, 
>> recording and 
>>> so on Maven output: precise use case still need to be described
>>> 
>>> 2. the discussion is not much about the api but about the default back-end 
>>> that will be shipped with Maven: there is no consensus, then the actual 
>>> strategy is to start with slf4j-simple in Maven 3.1.0 then have a vote to 
>>> choose which more complete implementation will go in Maven 3.1.1+
>>> 
>> 
>> We're blocked on using SLF4J Simple currently. We can wait for my patches to 
>> be reviewed, but we should probably start the vote for the implementation if 
>> that is what we require because after making several patches already I think 
>> it's just time to pick an implementation. As I said in my previous email 
>> we're so close to Christmas we might as well decide this and then fire up 
>> the release process in the new year after the logging implementation selection 
>> is made. It's highly unlikely that in the next few weeks testing a new 
>> version of Maven is going to be anyone's priority so we might as well take 
>> our time at this point.
>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> Le dimanche 9 décembre 2012 22:18:51 Chris Graham a écrit :
>>>> I got lost (in other work) and this thread a long time ago.
>>>> 
>>>> Can someone please remind me just why we are changing the logging at 
>> all?
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>> On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold <
>>>> 
>>>> kristian.rosenvold@gmail.com> wrote:
>>>>> 2012/12/9 Olivier Lamy <ol...@apache.org>:
>>>>>> Perso I'm fine using log4j2.
>>>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>>>> Log4j2 has quickly added a feature I needed and release it.
>>>>>> Furthermore I'm fine working with an Apache community in 
>> case of any
>>>>>> issue we could have.
>>>>> 
>>>>> I'm not entirely sure I follow where this discussion is 
>> actually
>>>>> going,  but I'm firmly opposed
>>>>> to including a brand new logging framework as default in m3.
>>>>> 
>>>>> Kristian
>>>>> 
>>>>> 
>> ---------------------------------------------------------------------
>>>>> 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
>>> 
>> 
>> 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
---------------------------------------------------------

The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, 
the search for a superior moral justification for selfishness.

 -- John Kenneth Galbraith

Re: Logging

[Mark Struberg <st...@yahoo.de>]

To be honest. Slf4J is really mature. The fact that we need some 'special treatment' for maven worries me.
Are we are trying to do things with slf4j-simple it never was intended for? Again: I think sjf4j is really mature, so I guess the error is on our side.
And you also mentioned that Ceki did special changes in slf4j _itself_ and not only the simple logger? That worries me even more, what changes have that been?


LieGrue,
strub



----- Original Message -----
> From: Jason van Zyl <ja...@tesla.io>
> To: Maven Developers List <de...@maven.apache.org>
> Cc: 
> Sent: Monday, December 10, 2012 8:33 AM
> Subject: Re: Logging
> 
> 
> On Dec 10, 2012, at 2:11 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> 
>>  trying to be concise and neutral
>> 
>>  1. because slf4j-api is well known, it has lots of back-ends, that will 
>>  provide powerfull configuration techniques for filtering, display, 
> recording and 
>>  so on Maven output: precise use case still need to be described
>> 
>>  2. the discussion is not much about the api but about the default back-end 
>>  that will be shipped with Maven: there is no consensus, then the actual 
>>  strategy is to start with slf4j-simple in Maven 3.1.0 then have a vote to 
>>  choose which more complete implementation will go in Maven 3.1.1+
>> 
> 
> We're blocked on using SLF4J Simple currently. We can wait for my patches to 
> be reviewed, but we should probably start the vote for the implementation if 
> that is what we require because after making several patches already I think 
> it's just time to pick an implementation. As I said in my previous email 
> we're so close to Christmas we might as well decide this and then fire up 
> the release process in the new year after the logging implementation selection 
> is made. It's highly unlikely that in the next few weeks testing a new 
> version of Maven is going to be anyone's priority so we might as well take 
> our time at this point.
> 
>>  Regards,
>> 
>>  Hervé
>> 
>>  Le dimanche 9 décembre 2012 22:18:51 Chris Graham a écrit :
>>>  I got lost (in other work) and this thread a long time ago.
>>> 
>>>  Can someone please remind me just why we are changing the logging at 
> all?
>>> 
>>>  -Chris
>>> 
>>> 
>>>  On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold <
>>> 
>>>  kristian.rosenvold@gmail.com> wrote:
>>>>  2012/12/9 Olivier Lamy <ol...@apache.org>:
>>>>>  Perso I'm fine using log4j2.
>>>>>  I use the branch I pushed for some weeks now and I'm happy.
>>>>>  Log4j2 has quickly added a feature I needed and release it.
>>>>>  Furthermore I'm fine working with an Apache community in 
> case of any
>>>>>  issue we could have.
>>>> 
>>>>  I'm not entirely sure I follow where this discussion is 
> actually
>>>>  going,  but I'm firmly opposed
>>>>  to including a brand new logging framework as default in m3.
>>>> 
>>>>  Kristian
>>>> 
>>>> 
> ---------------------------------------------------------------------
>>>>  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
>> 
> 
> 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: Logging

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

On Dec 10, 2012, at 2:11 AM, Hervé BOUTEMY <he...@free.fr> wrote:

> trying to be concise and neutral
> 
> 1. because slf4j-api is well known, it has lots of back-ends, that will 
> provide powerfull configuration techniques for filtering, display, recording and 
> so on Maven output: precise use case still need to be described
> 
> 2. the discussion is not much about the api but about the default back-end 
> that will be shipped with Maven: there is no consensus, then the actual 
> strategy is to start with slf4j-simple in Maven 3.1.0 then have a vote to 
> choose which more complete implementation will go in Maven 3.1.1+
> 

We're blocked on using SLF4J Simple currently. We can wait for my patches to be reviewed, but we should probably start the vote for the implementation if that is what we require because after making several patches already I think it's just time to pick an implementation. As I said in my previous email we're so close to Christmas we might as well decide this and then fire up the release process in the new year after the logging implementation selection is made. It's highly unlikely that in the next few weeks testing a new version of Maven is going to be anyone's priority so we might as well take our time at this point.

> Regards,
> 
> Hervé
> 
> Le dimanche 9 décembre 2012 22:18:51 Chris Graham a écrit :
>> I got lost (in other work) and this thread a long time ago.
>> 
>> Can someone please remind me just why we are changing the logging at all?
>> 
>> -Chris
>> 
>> 
>> On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold <
>> 
>> kristian.rosenvold@gmail.com> wrote:
>>> 2012/12/9 Olivier Lamy <ol...@apache.org>:
>>>> Perso I'm fine using log4j2.
>>>> I use the branch I pushed for some weeks now and I'm happy.
>>>> Log4j2 has quickly added a feature I needed and release it.
>>>> Furthermore I'm fine working with an Apache community in case of any
>>>> issue we could have.
>>> 
>>> I'm not entirely sure I follow where this discussion is actually
>>> going,  but I'm firmly opposed
>>> to including a brand new logging framework as default in m3.
>>> 
>>> Kristian
>>> 
>>> ---------------------------------------------------------------------
>>> 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
> 

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

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

trying to be concise and neutral

1. because slf4j-api is well known, it has lots of back-ends, that will 
provide powerfull configuration techniques for filtering, display, recording and 
so on Maven output: precise use case still need to be described

2. the discussion is not much about the api but about the default back-end 
that will be shipped with Maven: there is no consensus, then the actual 
strategy is to start with slf4j-simple in Maven 3.1.0 then have a vote to 
choose which more complete implementation will go in Maven 3.1.1+

Regards,

Hervé

Le dimanche 9 décembre 2012 22:18:51 Chris Graham a écrit :
> I got lost (in other work) and this thread a long time ago.
> 
> Can someone please remind me just why we are changing the logging at all?
> 
> -Chris
> 
> 
> On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold <
> 
> kristian.rosenvold@gmail.com> wrote:
> > 2012/12/9 Olivier Lamy <ol...@apache.org>:
> > > Perso I'm fine using log4j2.
> > > I use the branch I pushed for some weeks now and I'm happy.
> > > Log4j2 has quickly added a feature I needed and release it.
> > > Furthermore I'm fine working with an Apache community in case of any
> > > issue we could have.
> > 
> > I'm not entirely sure I follow where this discussion is actually
> > going,  but I'm firmly opposed
> > to including a brand new logging framework as default in m3.
> > 
> > Kristian
> > 
> > ---------------------------------------------------------------------
> > 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: Logging

[Chris Graham <ch...@gmail.com>]

I got lost (in other work) and this thread a long time ago.

Can someone please remind me just why we are changing the logging at all?

-Chris


On Sun, Dec 9, 2012 at 5:52 AM, Kristian Rosenvold <
kristian.rosenvold@gmail.com> wrote:

> 2012/12/9 Olivier Lamy <ol...@apache.org>:
> > Perso I'm fine using log4j2.
> > I use the branch I pushed for some weeks now and I'm happy.
> > Log4j2 has quickly added a feature I needed and release it.
> > Furthermore I'm fine working with an Apache community in case of any
> > issue we could have.
>
> I'm not entirely sure I follow where this discussion is actually
> going,  but I'm firmly opposed
> to including a brand new logging framework as default in m3.
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Logging

[Kristian Rosenvold <kr...@gmail.com>]

2012/12/9 Olivier Lamy <ol...@apache.org>:
> Perso I'm fine using log4j2.
> I use the branch I pushed for some weeks now and I'm happy.
> Log4j2 has quickly added a feature I needed and release it.
> Furthermore I'm fine working with an Apache community in case of any
> issue we could have.

I'm not entirely sure I follow where this discussion is actually
going,  but I'm firmly opposed
to including a brand new logging framework as default in m3.

Kristian

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

Re: Logging

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

2012/12/9 Jason van Zyl <ja...@tesla.io>:
> Hi,
>
> I sorted out the ITs running in embedded mode and here's what I came up with.
>
> I patched SLF4J Simple to work around some static initialization that locked in the log level and the output stream. So the problem in the ITs is not that the output doesn't arrive in the individual files for each IT, but that all the output is going into the file for the first IT. The same sort of problem arises where an IT expects a particular log level based error. The level is locked in for the suite that's run and can't be changed. The patch I made I have to talk to Ceki about as it's not terribly efficient but it works[1].
>
> I also brought the Logback branch up to date and it passes all the ITs. I think I'm at the point where it might make more sense to use a Logback as we're getting into non-simple use cases. I can get Ceki to look at my changes and cut a release if suitablle,  but honestly at this point I propose we integrate Logback.
>

Perso I'm fine using log4j2.
I use the branch I pushed for some weeks now and I'm happy.
Log4j2 has quickly added a feature I needed and release it.
Furthermore I'm fine working with an Apache community in case of any
issue we could have.

> I will put the branch of the grid tomorrow as I'm not sure what's going on with the CI builds for the ITs as they all seem to be misbehaving.
>
> [1]: https://github.com/jvanzyl/slf4j/commit/aa4b4545f59f84ae9f3122cc0311745ba6b3008e
>
> 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
>
>
>
>
>



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