On Nov 30, 2012, at 11:15 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote:
> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0 > If it's in 3.0.4 then you are using Mojo.getLog(), which is probably the ideal case, and this will work without change in 3.1.0. > Currently 3.0.4 does not provide either the api or an impl, so I need both > as a dependency.., > If you want to use SLF4J in 3.0.4 where is doesn't exist then yes. But I would just stick with Mojo.getLog(). > I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log > and part of the plugin jar (because it makes most sense to scope it there) > > What happens when that runs on 3.1.0? Can you give me a little plugin that demonstrates? I'm building a bunch of sample plugins now doing all the weird things we can think of. > > Oh and in my custom slf4j impl I actuall knock all the logging levels down > by 1, because this tool I am using is too verbose and what it spouts at > INFO is really DEBUG... So bypassing my impl would be a "bad thing" for > users You can control that with the configuration included, we have done that with Sisu to quiet it down. After chatting with Ceki I learned that it's not possible once SLF4J starts up to change the implementation. I don't think this is really a problem, the host system picks the implementation and that's what's used. So I think this is becoming rather clear that we should probably just pick the best implementation we can and go with it. > > On Friday, 30 November 2012, Jason van Zyl wrote: > >> For case 2) I would say only fork if your logging is know to interfere >> with standard SLF4J practices which I think would be rare. But I'll see how >> easy it is to implement a flag while I'm looking at this in general. >> >> On Nov 30, 2012, at 4:20 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >>> I tend to agree. There are two use-cases I see that a plugin has for >>> bundling a logging implementation: >>> >>> 1. They are wanting to shunt the logs from the build tool they are >> invoking >>> on to the user. Typically if they are being good plugins they just take >> the >>> logging output and shunt it onto org.apache.maven.plugin.Log.info() >>> >>> 2. They are wanting to shunt the logs from the build tool (or more likely >>> app server) to a separate file, or tweak the level of logs higher than >> INFO >>> for that app server/mojo execution as it will just drown the user. >>> >>> In the first use case, Jason's point is correct. They shouldn't need to >>> bundle a logging implementation any more. >>> >>> The second case, Jason is arguing that they shouldn't be using the Maven >>> JVM for running that tool, they should be running it in a forked JVM and >>> then they can configure the logging in that JVM. I disagree. Forking a >> JVM >>> for every little build tool just to control its logging is going to kill >>> the build time. >>> >>> My preference is for a metadata flag that says: Oy! I know what I'm doing >>> with logging, so don't pass logging on to me. >>> >>> While it feels like a "special case" the truth is logging is always, and >>> always will be, a special case! >>> >>> -Stephen >>> >>> >>> On 30 November 2012 12:09, Benson Margulies <bimargul...@gmail.com> >> wrote: >>> >>>> On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl <ja...@tesla.io> wrote: >>>>> >>>>> On Nov 29, 2012, at 5:56 PM, Benson Margulies <bimargul...@gmail.com> >>>> wrote: >>>>> >>>>>>> >>>>>>> Currently I'm of the mind that if you make a Maven plugin that uses >>>> something that employs SLF4J then the best practice is to only use the >> API >>>> and let the host choose the implementation, in our case Maven. Relying >> on >>>> SLF4J implementation specifics in a system you're embedded in is not >> good >>>> e.g. Logback in Sonar running in Maven using SLF4J Simple. If you want >> to >>>> your own logging thing while being invoked by Maven then you fork the >> JVM >>>> and then you can do whatever you want. >>>>>> >>>>>> I read Olivier's point to be this: it would be cool if we could think >>>>>> of a way for a plugin to use the slf4j API and remain independent of >>>>>> the logging workings of the maven core. >>>>> >>>>> I think you mean remain independent of the SLF4J implemented used by >>>> Maven's core. >>>>> >>>>> Sure, but my counter line of argument would be is that really valid? If >>>> you are running in the context of Maven and you're using SLF4J I think >> you >>>> should defer to what Maven has setup. >>>>> >>>>>> As things are, that could be >>>>>> done only, I think, by using shade to rename a copy of slf4j for the >>>>>> guts of the plugin. >>>>> >>>>> We have the capability in the core, that is OSGi-esque, that allows us >>>> to block classes from being accessible to plugins. We can block/allow >> any >>>> classes we choose: we can effectively make anything invisible to >> plugins if >>>> we choose. This capability was added to Classworlds some time ago. >>>>> >>>>>> If I were less sleep-deprived, I might be able to >>>>>> put forth an idea about how an enhancement to slf4j could allow >>>>>> everyone to be happy here, but I don't see a way to make everyone >>>>>> happy as things are. >>>>>> >>>>>> My personal view is that 'giant subsystem' plugins are rarities at >>>>>> most, and the attraction of saying 'the Maven logging API *is* slf4j' >>>>>> outweighs for me the problems. >>>>> >>>>> I think everyone agrees there, it's really now a matter would we let >>>> plugins pick and use a different implementation than the core. >>>>> >>>>>> >>>>>> However, another possibility that occurs to me 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
