On Fri, Dec 7, 2012 at 3:15 PM, Robert Scholte <rfscho...@apache.org> wrote: > If 3.1.0 is going to be the "New Logger"-release, I'd prefer to include the > colored logger as well. > That would make it more complete. Also, if coloring would require extra > adjustments to the logging framework then now is the time. (it seems to work > out of the box, but we have to be sure.)
I am -1 to a colored logger by default. The results look awful in circumstances that I spend time in, like emacs buffers. I think that we're much further from consensus about the presentation and management of a colored logger than we are from getting the base technology pushed. > > Robert > > > Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies > <bimargul...@gmail.com>: > >> As I see it, the vote bogged down because Kristian found problems, and >> I haven't seen clear evidence that those problems are sorted out. I'd >> be happy to vote +1 with respect to all the design questions for the >> release 'as is'. >> >> On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg <strub...@yahoo.de> wrote: >>> >>> good idea, Benson. >>> >>> Btw, this VOTE did not get enough +1 in more than a week. And this is not >>> because not enough people took care if you look at the plenty of comments in >>> the thread. >>> >>> 1.) Do people have any technical comment on my proposal to introduce a >>> new plugin-plugin flag for exposing slf4j? Is there any technical problem >>> with that? >>> >>> Are there other proposals which might help increasing backward >>> compatibility? >>> >>> >>> >>> 2.) what about the coloured logger with log4j2? I tried it locally and it >>> worked great. What is the status? (Sorry if I missed something) >>> >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> ----- Original Message ----- >>>> >>>> From: Benson Margulies <bimargul...@gmail.com> >>>> To: Maven Developers List <dev@maven.apache.org> >>>> Cc: >>>> Sent: Friday, December 7, 2012 2:28 PM >>>> Subject: Re: [VOTE] Maven 3.1.0 >>>> >>>> Could we please find an appropriate subject line for this debate, >>>> unless you all are really discussing this design question as part of >>>> the (still?) outstanding vote on 3.1.0? >>>> >>>> >>>> On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>>> >>>>> 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 >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
