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