2012/12/10 Hervé BOUTEMY <herve.bout...@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 <aherit...@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 <and...@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.conno...@gmail.com> wrote: >> >>> On Sunday, 9 December 2012, Kristian Rosenvold wrote: >> >>>> 2012/12/9 Olivier Lamy <ol...@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-unsubscr...@maven.apache.org<javascript:;> >> >>>> For additional commands, e-mail: dev-h...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
