I mentioned to Kristian that it wouldn't be hard to fix and that I would fix it before we released. Just been traveling this week. I'll fix it this weekend when I get home.
On Dec 7, 2012, at 6:04 AM, Benson Margulies <bimargul...@gmail.com> wrote: > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
