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

Reply via email to