still there have been twice as many problem reports as +1. Afaik we've never shipped a release in such a bad state to be honest.
LieGrue, strub ----- Original Message ----- > From: Benson Margulies <bimargul...@gmail.com> > To: Maven Developers List <dev@maven.apache.org>; Mark Struberg > <strub...@yahoo.de> > Cc: > Sent: Friday, December 7, 2012 3:04 PM > Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0 > > 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
