On Nov 29, 2012, at 4:47 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> I can hypothecate a use case, but I can't point to an example. > > Consider a plugin that sits on top of something large and complex, and > which logs, and which takes complete responsibility for its logging. Sure, I consider those endpoints, or applications. They consume a bunch of components and are the host. They should control everything the way they like. > It might, for example, have plugin parameters that control the logging > and the destination. Maybe. So far I've seen one plugin that tries to set the logging level. > > The users of that plugin will not be happy if a change to maven x.y > results in all this information being re-routed into Maven's Own Log, > instead of landing where their configuration tells it to land. If they are using SLF4 they are either a component to be embedded in which case the host is going to pick the implementation and the host controls the log output, or they are an application that we are wrapping and I'm not sure what to do there. In the case of Sonar it seems like we're wrapping an app because it expects Logback to be present. I don't think they use SLF4J correctly but I think they just try to use what they have for the app and the Maven plugin. Maybe Maven is different but consider other systems with plugins: JIRA, Confluence, Bamboo, Jenkins. Do they let the plugin authors do whatever they want with respect to logging? If so is that useful, not useful? If we block the implementation we force all plugin authors to specify an implementation even if they only use getLog() which to me is not ideal. If we let our implementation through then we are going to override the implementation specified by the component/app we are consuming which is what's happening with Sonar. I would like to avoid any magic of trying to detect implementations: in a single invocation of Maven what's the benefit of using multiple implementations of the SLF4J API? I don't see any. The Maven 3.1.0 version might be appropriate if we're saying "If you use SLF4J you must follow these guidelines, otherwise you will break." 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. > > --------------------------------------------------------------------- > 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 ---------------------------------------------------------
