FAQ
But not all of those *need to*. At least until now they have needed to, but
going forward they may not need to if we are giving them an slf4j impl to
hang their hat off.

There will always be some special case plugins that have a legitimate need
to do funky logging stuff. We need a strategy for those plugins.

Jason's proposal for those cases was that they should fork a JVM. That
works if you don't need to channel objects back and forth. For some of the
plugins wanting to do 'live development' style work (I am thinking my
jszip.org experiments - I have some plans and experiments that I haven't
even pushed to there yet ;-) ) forking a JVM is a bad plan, as you then
have to basically resort to RMI to control the forked JVM... More ports and
more sockets and more complexity.

The next step I could see is building a fresh classloader up from scratch
within the plugin. That *should* work as long as we load a fresh set of
slf4j-api classes (ceki?) then we are initialising slf4j a second time in
the fresh classloader and we can do as we need. Again complex though one
could argue less complex than the RMI route. Plugin developers following
this route will have to watch out for the dreaded CCE but at least you are
not having to deal with object serialisation and RMI

The final proposal that I see is where we give a metadata flag (defaults to
false) which if true sets up an isolated classloader for the plugin
allowing the plugin to use its own slf4j

Note that each proposal above retains the option for plugin developers to
use the previous proposal.

My vote is that we need to provide a utility library that makes the first
and second proposals facile for plugin developers and we should probably
enable the third option also.

The correct respecting of tool chains support requires plugin developers to
follow the first route if a tool chain JVM is applied to their plugin and
to use the second when no tool chain JVM is in play... At least for the
jetty:run and tomcat:run style plugins.

For the sonar style plugins, and my gut says the vast majority of these use
cases the most they will need is the third proposal. Without seeing a
maven-fork-utils api I cannot say that we don't need the third proposal, so
I am forced to conclude that we should support it... IOW I think we need a
metadata flag.

-Stephen
On Friday, 7 December 2012, Mark Struberg wrote:

basically all stuff which integrates maven does *funky logging stuff*...



----- Original Message -----
From: Anders Hammar <anders@hammar.net <javascript:;>>
To: Maven Developers List <dev@maven.apache.org <javascript:;>>
Cc:
Sent: Friday, December 7, 2012 7:25 AM
Subject: Re: [VOTE] Maven 3.1.0
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. 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
<bimargulies@gmail.com>
wrote:
On Thu, Nov 29, 2012 at 11:05 PM, Jason van Zyl
<jason@tesla.io>
wrote:
On Nov 29, 2012, at 5:56 PM, Benson Margulies
<bimargulies@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 y

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase