Boils down to 1) pick a logging facade and 2) pick a default implementation.
SLF4J is really the de facto standard, used everywhere including 15 projects here at Apache. It's unlikely to be surprising to anyone with the changes I've made as it will appear just like it does now. A bunch of log statement to the console. It's unlikely any plugin author is going to care about changing the implementation as its running inside Maven. Integrators may want to change the implementation to control how components and plugins log but the authors of plugins should not have to care. SLF4J accompanying utilities also help to sequester log output from commons logging and JUL into the same funnel. So even if plugin authors are pulling in component we could add the adapters and bridges to make this all work nicely. So even if something is using commons-logging or JUL under the covers it will all come out, ultimately, through SLF4J. Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what components use what logging framework. On Sep 9, 2012, at 12:43 PM, Benson Margulies wrote: > On Sun, Sep 9, 2012 at 12:38 PM, Mark Struberg <[email protected]> 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 <[email protected]> >>> To: Maven Developers List <[email protected]>; Mark Struberg >>> <[email protected]> >>> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
