> 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. 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
