Again, let's deal with this one thing at a time: 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in favor, because it's much more common and popular than plexus.
2. Picking an slf4j-X to deliver logging to somewhere. I'm somewhat in favor of java.util.logging for this, because of the baroque classpath interactions of log4j initialization. But if others prefer log4j or even something else, OK. 3. Tossing one or more X-slf4j bridges into the default plugin classpath. If Mark's concerns about surprises have any foundations in technical reality, this is where they would turn up. I'm doubtful, but on the other hand, what if we just didn't do this, and left it to individual plugin authors to do this if, in fact, they wanted mapping from some other logging API? It would be good for some others to join this discussion. On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl <ja...@tesla.io> wrote: > I think you're trying to preemptively solve for an issue that we may not > have. I believe that if the right JARs are in the classpath first we will > easily be able to tell running the integration tests for Maven and the > integration tests for all the plugins if there's going to be an issue. I > believe the Ceki has probably run into every integration scenario imaginable > over the last 10 years and he'll help us if required. > > I have runt into nasty problems where the classpath and classloaders cannot > be controlled directly from the host system, but this is obviously within our > purview to control. > > On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote: > >> >>> 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 >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > A man enjoys his work when he understands the whole and when he > is responsible for the quality of the whole > > -- Christopher Alexander, A Pattern Language > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
