basically all stuff which integrates maven does *funky logging stuff*...
----- Original Message ----- > From: Anders Hammar <and...@hammar.net> > To: Maven Developers List <dev@maven.apache.org> > Cc: > Sent: Friday, December 7, 2012 7:25 AM > Subject: Re: [VOTE] Maven 3.1.0 > >> I'm interested to help working on adding a metadata to enable slf4j >> visibility >> from a plugin: by default, slf4j is not visible, plugins are expected to >> use >> plugin-api's Log. But if the plugin wants to use core's slf4j, he > would be >> able to add an annotation in the goal requiring shared core slf4j, then the >> plugin descriptor would enable slf4j api import from core. >> > > *If* we go this path, I think the default should be the other way around. > I.e., the default would be to use core's slf4j and it's impl. So the > plugin > developer needs to do an active choice to go outside Maven's logging. Sure, > this could imply problems with existing plugins doing funky logging stuff > (like the Sonar plugin), but I don't really see a problem with those > plugins having to release a new version. I think it's more important that > we get good defaults than trying to make every existing plugin work as they > are implemented right now. > > /Anders > > >> >> Stephen: is this what you have in mind? >> >> Regards, >> >> Hervé >> >> Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : >> > 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 >> >> --------------------------------------------------------------------- >> 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
