> > 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.
I don't consider them broken. I consider them fixed. Old plugins that use SLF4J now get there information properly integrated with the rest of the maven information. Dan On Dec 7, 2012, at 7:32 AM, Mark Struberg <strub...@yahoo.de> wrote: >> 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
