That's all broken by design as already predicted 2 months ago.

Imo the only portable way is to NOT expose slf4j in the Core Realm at all.
The other way would be to introduce a plugin-plugin configuration which says 
logging yes/no.

LieGrue,
strub




----- Original Message -----
> From: Stephen Connolly <stephen.alan.conno...@gmail.com>
> To: Maven Developers List <dev@maven.apache.org>
> Cc: 
> Sent: Friday, November 30, 2012 8:15 PM
> Subject: Re: [VOTE] Maven 3.1.0
> 
> What about the case where a plugin needs to work with both 3.0.4 and 3.1.0
> 
> Currently 3.0.4 does not provide either the api or an impl, so I need both
> as a dependency..,
> 
> I'm being a good boy, so my impl is custom to route through to o.a.m.p.Log
> and part of the plugin jar (because it makes most sense to scope it there)
> 
> What happens when that runs on 3.1.0?
> 
> Oh and in my custom slf4j impl I actuall knock all the logging levels down
> by 1, because this tool I am using is too verbose and what it spouts at
> INFO is really DEBUG... So bypassing my impl would be a "bad thing" 
> for
> users
> 
> On Friday, 30 November 2012, Jason van Zyl wrote:
> 
>>  For case 2) I would say only fork if your logging is know to interfere
>>  with standard SLF4J practices which I think would be rare. But I'll see 
> how
>>  easy it is to implement a flag while I'm looking at this in general.
>> 
>>  On Nov 30, 2012, at 4:20 AM, Stephen Connolly <
>>  stephen.alan.conno...@gmail.com> wrote:
>> 
>>  > 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
>

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

Reply via email to