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. > > 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
