> > 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. 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. 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. 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. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org