On Friday, 7 December 2012, Anders Hammar wrote: > > I'm interested to help working on adding a metadata to enable slf4j > > visibility > > from a plugin: by default, slf4j is not visible, plugins are expected to > > use > > plugin-api's Log. But if the plugin wants to use core's slf4j, he would > be > > able to add an annotation in the goal requiring shared core slf4j, then > the > > plugin descriptor would enable slf4j api import from core. > > > > *If* we go this path, I think the default should be the other way around. > I.e., the default would be to use core's slf4j and it's impl. So the plugin > developer needs to do an active choice to go outside Maven's logging.
+1 > Sure, > this could imply problems with existing plugins doing funky logging stuff > (like the Sonar plugin), but I don't really see a problem with those > plugins having to release a new version. I think it's more important that > we get good defaults than trying to make every existing plugin work as they > are implemented right now. > > /Anders > > > > > > Stephen: is this what you have in mind? > > > > Regards, > > > > Hervé > > > > Le vendredi 30 novembre 2012 12:20:35 Stephen Connolly a écrit : > > > I tend to agree. There are two use-cases I see that a plugin has for > > > bundling a logging implementation: > > > > > > 1. They are wanting to shunt the logs from the build tool they are > > invoking > > > on to the user. Typically if they are being good plugins they just take > > the > > > logging output and shunt it onto org.apache.maven.plugin.Log.info() > > > > > > 2. They are wanting to shunt the logs from the build tool (or more > likely > > > app server) to a separate file, or tweak the level of logs higher than > > INFO > > > for that app server/mojo execution as it will just drown the user. > > > > > > In the first use case, Jason's point is correct. They shouldn't need to > > > bundle a logging implementation any more. > > > > > > The second case, Jason is arguing that they shouldn't be using the > Maven > > > JVM for running that tool, they should be running it in a forked JVM > and > > > then they can configure the logging in that JVM. I disagree. Forking a > > JVM > > > for every little build tool just to control its logging is going to > kill > > > the build time. > > > > > > My preference is for a metadata flag that says: Oy! I know what I'm > doing > > > with logging, so don't pass logging on to me. > > > > > > While it feels like a "special case" the truth is logging is always, > and > > > always will be, a special case! > > > > > > -Stephen > > > > > > On 30 November 2012 12:09, Benson Margulies <bimargul...@gmail.com> > > wrote: > > > > On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl <ja...@tesla.io> > > wrote: > > > > > 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 >
