On Sun, Sep 9, 2012 at 4:19 PM, Mark Struberg <strub...@yahoo.de> wrote: > 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.
Of course plugins can add bridges that mapped in their favorite framework in Jason's scheme. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
