On Sep 9, 2012, at 3:14 PM, Anders Hammar wrote: > 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. >
Well, we can if we want for additions. But this method doesn't require it. Have to live with your baggage. Forever. But that doesn't mean you can't make improvements and I think using SLF4J is one of these improvements. >> 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 > 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
