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'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.
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
Maven
and
kill
doing
and
wrote:
bimargulies@gmail.com
uses
the
by
valid?
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 :
likelyRegards,
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
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
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
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
JVM for running that tool, they should be running it in a forked JVM
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
for every little build tool just to control its logging is going to
the build time.
My preference is for a metadata flag that says: Oy! I know what I'm
My preference is for a metadata flag that says: Oy! I know what I'm
with logging, so don't pass logging on to me.
While it feels like a "special case" the truth is logging is always,
While it feels like a "special case" the truth is logging is always,
always will be, a special case!
-Stephen
On 30 November 2012 12:09, Benson Margulies <bimargulies@gmail.com>
wrote:-Stephen
On 30 November 2012 12:09, Benson Margulies <bimargulies@gmail.com>
On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl <jason@tesla.io>
On Nov 29, 2012, at 5:56 PM, Benson Margulies <
wrote:
Currently I'm of the mind that if you make a Maven plugin that
something that employs SLF4J then the best practice is to only use
API
Relyingand let the host choose the implementation, in our case Maven.
on
good
wantSLF4J implementation specifics in a system you're embedded in is not
e.g. Logback in Sonar running in Maven using SLF4J Simple. If you
to
JVM
think
ofyour own logging thing while being invoked by Maven then you fork the
and then you can do whatever you want.
I read Olivier's point to be this: it would be cool if we could
of a way for a plugin to use the slf4j API and remain independent
the logging workings of the maven core.
I think you mean remain independent of the SLF4J implemented usedMaven's core.
Sure, but my counter line of argument would be is that really
If
thinkyou are running in the context of Maven and you're using SLF4J I
you
the
us
any
plugins
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
done only, I think, by using shade to rename a copy of slf4j for
guts of the plugin.
We have the capability in the core, that is OSGi-esque, that allowsto block classes from being accessible to plugins. We can block/allow
classes we choose: we can effectively make anything invisible to
