First, I also would recommend moving from plexus logging to SLF4J. Mark's concerns with incompatibilities only come about with the log4j bridge if you are trying to use APis that the SLF4J bridge hasn't implemented. Something being used in a plugin really shouldn't be using those.
Although Ceki is generally careful not to break compatibility, it has happened. For example, you cannot mix applications that use SLF4J 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much tied to the SLF4J version. See http://www.slf4j.org/news.html. If core is using SLF4J and an incompatible change is made again it probably won't be that big of a deal. Typically, when compatibility has been broken it really hasn't impacted code that uses the SLF4J API. Mark mentioned shading as a way to "fix" any problems with SLF4J conflicts. I am not sure if shading will work with SLF4J. Implementations must provide a class named org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder and org.slf4j.impl.StaticMDCBinder. Jason made a comment in a previous reply that said "Ceki is also a committer, and will help us fix anything when necessary so that, again, we can focus on Maven and not logging." http://people.apache.org/committer-index.html doesn't list him as a committer on Maven and Ceki has said publicly and privately that he is unlikely to contribute to ASF projects. However, while the statement is incorrect I don't understand why what Ceki would or wouldn't do would have any bearing on whether Maven adopts SLF4J. Finally, I've been working on Log4j 2 for over 3 years now. The reason I started working on it was due to deficiencies in Logback that occur in large scale web applications and probably don't matter in something like Maven. But it would be nice to allow the end user the ability to swap out the logging implementation if they want. Ralph On Sep 9, 2012, at 12:44 PM, Benson Margulies wrote: > On Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg <[email protected]> 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 <[email protected]> >>> To: Maven Developers List <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>>>> To: Maven Developers List <[email protected]> >>>>>>> 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 >>> <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>>>> To: Maven Developers List >>> <[email protected]>; Mark >>>>>>> Struberg <[email protected]> >>>>>>>>>> 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: >>> [email protected] >>>>>>>>> For additional commands, e-mail: >>> [email protected] >>>>>>>>> >>>>>>>> >>>>>>>> >>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>> >>>>>>> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
