+1 maybe we should first try to clarify what to use slf4j for.
slf4j has 2 'adaptors' 1.) you can use the slf4j-api as logging facede to log to any logging backend you like. Be it log4j, logback, etc. In that case you use the slf4j API in your project 2.) you can use slf4j as 'bridge' to other logging frameworks. Your application e.g. 'talks' log4j, commons-logging or jul and slf4j provides an implementation for (most of, but sadly not all) of the log4j, etc API and bridges it to slf4j. Any others I missed? 1.) is perfectly possible but we have a logging facade already in place: plexus.Logger. This stuff exists since a long time and is used in all Maven APIs. It would be hard to replace this with SLF4J and I personally see no technical reason to do so. 2.) What happens if a plugin in your build already has a native log4j.jar, commons-logging.jar, etc already in the classpath? In my experience it will cause weird class cast exceptions. Which is not what we want. If someone explains me that/how 2. works without introducing possible compat issues, then I'm +1 for SLF4j as well. LieGrue, strub ----- Original Message ----- > From: Benson Margulies <bimargul...@gmail.com> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Sunday, September 9, 2012 6:43 PM > Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in > /maven/maven-3/trunk: ./ apache-maven/ > maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ > maven-embedder/src/main/java/org/apache/maven/cli/] > > On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg <strub...@yahoo.de> wrote: >> sorry, didn't catch this reply earlier. >> >> I see, but then we are back to my original problem. Once you add e.g. > log4j-slf4j binding then you will get nasty class cast exceptions because > they > are not fully binary compatible. If there is a log4j.jar in the classpath of > the > plugin already then it might even crash with a weird Exception. > > Folks, I'm sorry, but I'm not following this argument. I apologize for > being slow, but I really wish that someone would sort this into a > small number of questions and explain the pros and cons of them. > > I'm fine with declaring SLF4J to be the primary logging API inside > Maven, and leaving it to individual plugin authors to toss in X-slf4j > if they want to. I can see why putting X-slf4j into the plugin > classpath by default could have surprising and unpleasant results, but > there might be a persuasive reason to do it anyway. > > > >> >> >> I've seen such problems in the wild. >> This is nothing which slf4j does wrong - it's just not really possible > to do it 100% right. >> >> We imo only have the option to choose between different kinds of > 'broken'. >> >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Jason van Zyl <ja...@tesla.io> >>> To: Maven Developers List <dev@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> >>> Cc: >>> Sent: Sunday, September 9, 2012 4:22 PM >>> Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in > /maven/maven-3/trunk: ./ apache-maven/ > maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ > maven-embedder/src/main/java/org/apache/maven/cli/] >>> >>> >>> On Sep 9, 2012, at 4:17 AM, Mark Struberg wrote: >>> >>>> Can you again please explain me what the benefit of the SLF4J > abstraction >>> over the already used plexus.Logger is? Both are just logging facades. >>>> >>> >>> But really I think the biggest benefit is that, as far as I know, SLF4J >>> integrates with every known logging framework right now. In that it can > coerce >>> JUL, and CL logging into a unified framework which I don't believe > any of >>> the other frameworks do, or do as well. Maven is about integration and > for >>> logging I believe it's the best solution that exists for the least > effort. >>> >>> I think it's been adopted at Apache by so many projects > specifically for >>> those reasons. Ceki is also a committer, and will help us fix anything > when >>> necessary so that, again, we can focus on Maven and not logging. >>> >>> 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 >>> >> >> --------------------------------------------------------------------- >> 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
