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



----- Original Message -----
> From: Anders Hammar <and...@hammar.net>
> To: Maven Developers List <dev@maven.apache.org>
> 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 
> <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
>>  > > if
>>  > > we choose. This capability was added to Classworlds some time 
> ago.
>>  > >
>>  > > >> 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.
>>  > > >
>>  > > > I think everyone agrees there, it's really now a matter 
> would we let
>>  > >
>>  > > plugins pick and use a different implementation than the core.
>>  > >
>>  > > >> 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.
>>  > > >
>>  > > > That's the magic I would like to avoid. Anything is 
> possible but I
>>  would
>>  > >
>>  > > prefer how a plugin author should integrate with our SLF4J 
> logging.
>>  > >
>>  > > Here's the crux of the disagreement. To be clear, I'm not 
> trying to
>>  > > derail any 3.1.0 trains here, just thinking ahead.
>>  > >
>>  > > A logging framework is a tool for collecting and distributing
>>  > > information. When someone plugs 'thing X' into Maven, I 
> don't think
>>  > > that it follows, necessarily, that their application of a logging
>>  > > framework necessarily aligns with ours. We are logging 'the 
> build' --
>>  > > they are logging 'whatever it is that they are doing'. 
> They may log
>>  > > thousands of messages at 'INFO' that are only interesting 
> to some
>>  > > program that digests them, like Apache Flume. That's going to 
> make an
>>  > > awfully hard-to-read console. If we stick to your view, their 
> only
>>  > > option is to mess with the global Maven logging config to reroute
>>  > > their messages, and that's very out of keeping with the whole 
> model of
>>  > > maven plugins as self-contained.
>>  > >
>>  > > I am content to wait for the first JIRA from someone who has this
>>  > > issue, and then advocate for the magic, rather than continue an
>>  > > argument right now.
>>  > >
>>  > > >> 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.
>>  > > >
>>  > > > Given this is 3.1.0 I believe it's more a matter of 
> documenting how
>>  > >
>>  > > plugin should integrate their logging with Maven's SLF4J 
> system. An app
>>  > > server which may integrate all manner of things works. If you 
> want to
>>  > > integrate with me, this is how you need to do it.
>>  > >
>>  > > >>
>>  ---------------------------------------------------------------------
>>  > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>  > > >> For additional commands, e-mail: 
> dev-h...@maven.apache.org
>>  > > >
>>  > > > Thanks,
>>  > > >
>>  > > > Jason
>>  > > >
>>  > > > ----------------------------------------------------------
>>  > > > Jason van Zyl
>>  > > > Founder & CTO, Sonatype
>>  > > > Founder,  Apache Maven
>>  > > > http://twitter.com/jvanzyl
>>  > > > ---------------------------------------------------------
>>  > > >
>>  > > > believe nothing, no matter where you read it,
>>  > > > or who has said it,
>>  > > > not even if i have said it,
>>  > > > unless it agrees with your own reason
>>  > > > and your own common sense.
>>  > > >
>>  > > >  -- Buddha
>>  > >
>>  > > 
> ---------------------------------------------------------------------
>>  > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>  > > For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>  For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to