On Sep 9, 2012, at 4:19 PM, Mark Struberg 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 >
With what I've done you can use plexus.Logger if you like until the end of time, as can anyone else. Nothing forcing you to use anything else. If you don't see the benefit don't use it. I haven't, nor do I plan or suggest, removing the interface. I think SLF4J as an interface is better long-term for integration. As a replacement of one interface over another who cares really but it's all the ancillary benefits of everything that comes with SLF4J. > It would make sense if plugins could add a logging bridge which is used by > 'their' framework. Probably possible, I'll ask Ceki how it could best be done. > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
