sorry, you are right, should have been slf4j-simple, etc.
----- Original Message ----- > From: Anders Hammar <and...@hammar.net> > To: Maven Developers List <dev@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 <dev@maven.apache.org> >> > Cc: >> > Sent: Monday, December 10, 2012 9:25 AM >> > Subject: Re: Logging >> > >> > 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 >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
