The version that is currently staged (code name alpha-5 in my book) has an unsolved problem with the logging and verifier.
I assume we'll stage a new version (code name "beta-1") when that's done, at which point I'm more than ready to ship. I'm not fixing any more stuff on core now, and I'm half-assuming jason will fix the logging. Jason, do ping me on irc if you need a second set of eyes on solving the problem, even though I'm incompetent with logging ;) Kristian 2012/12/7 Benson Margulies <bimargul...@gmail.com>: > As I see it, the vote bogged down because Kristiathe loggingn 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
