On Fri, Nov 30, 2012 at 7: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.
I'd be happier with forking if we had a maven-fork-utils project that allowed any plugin author, easily, to have as many forks at his or her place-setting as we see in, say, surefire. > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org