nope, no problem with just slf4j api and logback. But that wont give us much benefit over just using plexus.Logger. At least I do not see it yet
It would make sense if plugins could add a logging bridge which is used by 'their' framework. But otoh we have already kind of a bridge by grabbing the stdout and redirecting that to the plexus logger. LieGrue, strub ----- Original Message ----- > From: Benson Margulies <bimargul...@gmail.com> > To: Maven Developers List <dev@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> > Cc: > Sent: Sunday, September 9, 2012 9:44 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 Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg <strub...@yahoo.de> wrote: >> >>> No client code changes unless the client wants to change it to take > advantage of >>> SLF4J. >> >> It's not the classes which change but the classpath does. It might then > contain clashing classes. That is what I'm afraid of to be honest. Because > we do not have the 'other side' (random plugins and projects) under our > own control. > > So, to be clear, we are not talking about the bridges *at all*. > > Thus, I claim that Mark's concern boils down to the following: Let's > say that we add slf4j-api, slf4j-logback, and logback-whatever to the > classpath. If I am following, you are worried that some plugin author > somewhere is already using logback with a different version and might > get an unpleasant surprise when the version we pick shows up. > > I find this scenario hard to credit. However, if it really worried us, > we could shade the back end, and then the only possible means for > trouble would be a plugin that wanted to use an incompatible version. > > If that's not what's worrying you, please humor me with a complete, > concrete, example. If it is, can you cite an example of an existing > plugin that would bust? > > > >> >> >> 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 8:43 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 2:24 PM, Benson Margulies wrote: >>> >>>> 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. >>>> >>> >>> Yah, it's SLF4J so pick an implementation. >>> >>>> 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? >>> >>> I'm not suggesting this. I've routed the Mojo.getLog() through > SLF4J so >>> it just does what it does now except the backing implementation is the > SLF4J >>> implementation. If the user wants to use SLF4J and/or @Inject loggers > than they >>> have to specify the dependency. >>> >>> No client code changes unless the client wants to change it to take > advantage of >>> SLF4J. >>> >>>> >>>> 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 >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder & CTO, Sonatype >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> I never make the mistake of arguing with people for whose opinions I > have no >>> respect. >>> >>> -- Edward Gibbon >>> >> >> --------------------------------------------------------------------- >> 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
