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
