I'll join. :-) > 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.
Me too. And I'm even arguing we should try to switch to slf4j in core. Sure, no real technical advantage, but I believe it's easier for other people coming in and understanding the code if we don't use old (deprecated?) APIs. > 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. logback would be my pick. > 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? Not sure we should add stuff "just in case". I mean, which ones should we pick? I kind of think it should be none or all. But all would be impossible I think as it would include stuff we haven't heard of before. > It would be good for some others to join this discussion. Thanks for bringing this discussion down to the pace of us slower people! /Anders > > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
