I join too ;) IMO mvn doesnt need logback or slf4j at all. If you want to get rid of your log facade use juli to create a new one (as cxf or owb does). Dont mess the classpath with slf4j which has its drawbacks too Le 9 sept. 2012 21:44, "Benson Margulies" <bimargul...@gmail.com> a écrit :
> 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 > >
