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
>

Reply via email to