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
