>I don't believe it's valid to just let everyone do whatever they want.
Well, I think this is the fundamental point we disagree on. Maven is not only a build system but also a container which runs user specific stuff. And a container should try to isolate as much internal details from it's users as he can. So yes, imo we should let everyone do whatever they want! By forcing some specific logging mechanism on any users we will heavily restrict plugin programmers. And sometimes even the plugin programmers cannot change anything because the are only 'users' of the library the plugin uses. I personally believe we will introduce quite some backward incompatibility. Plugins which didn't use slf4j will not see any difference. And plugins and frameworks which used slf4j will loose control over their logging. I'd be happy to be proved wrong... LieGrue, strub >________________________________ > From: Jason van Zyl <ja...@tesla.io> >To: Maven Developers List <dev@maven.apache.org>; Mark Struberg ><strub...@yahoo.de> >Sent: Friday, November 30, 2012 9:08 PM >Subject: Re: [VOTE] Maven 3.1.0 > > > > >On Nov 30, 2012, at 11:55 AM, Mark Struberg <strub...@yahoo.de> wrote: > >That's all broken by design as already predicted 2 months ago. >> >> > > >It is not broken by design and you're not being helpful. Retreating into >trying to implement all this ourselves is not a solution. Try it Mark, >implement your system and ignore everything that's been done and I predict >you're going to end up in the exact same place because integrating many >systems in a common way is hard. This is the nitty gritty of integration, it's >ugly to make it work but that's always the way it is. > > >We're still going to end up in the same place and it's not impossible to >change the way the binding works in SLF4J and it's been requested, but the >entire world of use of SLF4J doesn't seem to see it as a problem. > >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. >> >> > > >I don't believe it's valid to just let everyone do whatever they want. The >only problem we've seen thus far is a problem where it's clearly a misuse of >the SLF4J API. I still argue that the implementation used by the core can be >used by plugins and letting arbitrary implementations and arbitrary >manipulation of the logging system isn't really that valuable in compared to >having a a consistent pattern that's used by so many others. > >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 >> >> > >Thanks, > >Jason > >---------------------------------------------------------- >Jason van Zyl >Founder & CTO, Sonatype >Founder, Apache Maven >http://twitter.com/jvanzyl >--------------------------------------------------------- > > >There's no sense in being precise when you don't even know what you're talking about. > > -- John von Neumann > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
