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 is this: >>>> >>>> Allow a plugin's metadata to say: 'please leave slf4j isolated here'. >>>> Such a plugin could only log to the Maven log through the Mojo log >>>> API. >>> >>> That's the magic I would like to avoid. Anything is possible but I would >> prefer how a plugin author should integrate with our SLF4J logging. >> >> Here's the crux of the disagreement. To be clear, I'm not trying to >> derail any 3.1.0 trains here, just thinking ahead. >> >> A logging framework is a tool for collecting and distributing >> information. When someone plugs 'thing X' into Maven, I don't think >> that it follows, necessarily, that their application of a logging >> framework necessarily aligns with ours. We are logging 'the build' -- >> they are logging 'whatever it is that they are doing'. They may log >> thousands of messages at 'INFO' that are only interesting to some >> program that digests them, like Apache Flume. That's going to make an >> awfully hard-to-read console. If we stick to your view, their only >> option is to mess with the global Maven logging config to reroute >> their messages, and that's very out of keeping with the whole model of >> maven plugins as self-contained. >> >> I am content to wait for the first JIRA from someone who has this >> issue, and then advocate for the magic, rather than continue an >> argument right now. >> >>> >>>> >>>> I may be understating the strength of Olivier's (and others') desire >>>> to avoid surprising the authors of plugins that call things that call >>>> slf4j, though I can see 'surprise' in both directions here in the long >>>> run. >>> >>> Given this is 3.1.0 I believe it's more a matter of documenting how >> plugin should integrate their logging with Maven's SLF4J system. An app >> server which may integrate all manner of things works. If you want to >> integrate with me, this is how you need to do it. >>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 ---------------------------------------------------------
