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 <[email protected]> > To: Maven Developers List <[email protected]> > Cc: > Sent: Monday, December 10, 2012 9:25 AM > Subject: Re: Logging > > 2012/12/10 Hervé BOUTEMY <[email protected]>: >> 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 <[email protected]> > 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 > <[email protected]> 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 < >>> >> >>> >> [email protected]> wrote: >>> >>> On Sunday, 9 December 2012, Kristian Rosenvold wrote: >>> >>>> 2012/12/9 Olivier Lamy <[email protected] > <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: > [email protected]<javascript:;> >>> >>>> For additional commands, e-mail: > [email protected] >>> >> >>> >> <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: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
