On Nov 30, 2012, at 4:09 AM, Benson Margulies <bimargul...@gmail.com> wrote:
>> >> 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. > These are good discussions and it's important to make sure we try some things because one we let this out it's going to be hard to pull back. If we roll it five more times I don't think that's a problem and I don't mind rolling it again and again. But I shouldn't send email right before going to bed and I should have looked at the realms because we're not exporting the package that contains the SLF4J implementation, we are only exporting the API if you look at the DefaultClassRealmManager. I will try something here locally but after looking again I think plugins will be fine because the Plugin API is exported and therefore users have access to the implementation of SLF4J used in the core without exposing it, and the implementation is also available through injection or using the static LoggerFactory method. I will verify that now. I think the problem with Sonar is misuse of the API and Simon agrees with me but I don't want to break Sonar users. > 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. If you are running something like Flume that also has the possibly of making your CI server fall over I would not run that in-process. If they fork and run it in isolation I believe they will have not have to contend with what we've setup for logging. > > 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 think it's setup now the way we want, we just happen to have an unfortunate use of the API in Sonar but I think we're going to have to deal with that. If 3.1.0 comes out and Sonar doesn't work I don't think that's acceptable even though it's not really our fault. >> >>> >>> 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 --------------------------------------------------------- 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
