Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release.
On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg <strub...@yahoo.de> wrote: > Daniel, please think through these old project scenarios. Those old > projects did ship their own slf4j impl + config and parsed their own logs > and extracted information. They will now just fall on their knees because > the logs are no longer available for them. Instead they will be somewhere > in the maven logs which could be anywhere from a plugin point of view. > > > This is not fixed, this is broken imo. > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Daniel Kulp <dk...@apache.org> > > To: Maven Developers List <dev@maven.apache.org> > > Cc: > > Sent: Friday, December 7, 2012 1:49 PM > > Subject: Re: [VOTE] Maven 3.1.0 > > > > > >> > >> 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
