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
