>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
Stephen, this is _almost_ the same as I proposed a month ago. But I'd do it the other way around as this would be perfectly backward compatible. I'll try to explain again what I propose: Any plugin could e.g. use a @Slf4JLogger in it's mojo. The plugin-plugin would transfer this to a <useSlf4j>true</useSlf4j> inside the plugin.xml. In this case, and _only_ in this case we would expose our internal SLF4J to the plugin. Older plugins do not need it anyway as they do not use the maven-provided slf4j yet! This is a win-win solution imo: * old integration and plugins will still work * new plugins can use slf4j for logging via maven Again the state of affairs of 3.1.0 today: old projects and plugins which didnt use slf4j so far don't get any benefit from forcing slf4j on them. And old projects and plugins which _did_ use slf4j already are now broken with the current trunk. I cannot see how we can seriously release this to users right now. LieGrue, strub >________________________________ > From: Stephen Connolly <stephen.alan.conno...@gmail.com> >To: Maven Developers List <dev@maven.apache.org>; Mark Struberg ><strub...@yahoo.de> >Sent: Friday, December 7, 2012 12:48 PM >Subject: Re: [VOTE] Maven 3.1.0 > > >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 <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 y > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
