> Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what > components use what logging framework. Yes, only that this sometimes causes really unfriendly classcast exceptions :/
How can we deal with those? Is there a retry possible? Imo not easily. Could we scan the plugin classpath upfront? Can a different class lookup strategy in our ClassRealms help? Don't we care at all and people must exclude log4j et all manually if they like to use a new maven version? LieGrue strub ----- Original Message ----- > From: Jason van Zyl <ja...@tesla.io> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Sunday, September 9, 2012 7:08 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/] > > 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 <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 >> > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
