Nothing has been released yet. This is what this cycle is for and frankly after 11 months of not releasing while adding JSR330 and SLF4J it's to be expected. But Hervé is working on it and I'm fixing up the error Kristian verified so it's getting review and if it takes 5 more re-spins so be it.
The cycle for 3.1.0 is the cycle that should be happening to prevent something we're not happy with from being released. Unlike, say, the compiler plugin which was actually released without much review only for Dan to discover after the fact it doesn't work as advertised[1]. It always happens where after a huge hiatus no one really thinks about the release until it starts happening and then everyone wants things put in. We decided to call it 3.1.0 which to me signifies some breakage. For me that is the SLF4J API being used correctly and potentially breaking people. Hervé wants to try and preserve existing behavior which is fine. No rush and he's going to try and implement that. All in all we have still only seen one breakage in the field from the misuse of the SLF4J API. So I would hardly call this the worst state the core's been in. The only way to figure out what works, or doesn't, is to make a sample set of plugins with the various options for logging and validate their behavour. I think we should also consider calling this 3.0.5 because there are probably a lot of behaviours we do want to change. A couple things I can think of are not automatically downloading snapshots every 24 hours, or changing the behaviour of local downloads to check the SHA1 and not the server it came from. These two behaviours cause lots of problems. If we collected all those together and wanted to implement them I think that is a reason to change a major version. Most users don't care about our API changes they care about feature changes and behavioural changes. People are going to look at 3.1.0 and ask what's different for them and the answer is nothing really. [1]: https://jira.codehaus.org/browse/MCOMPILER-187 This is whole point of this cycle. Nothing has been released yet, folks have been reviewing it and we're now fixing more things. On Dec 7, 2012, at 9:39 AM, Mark Struberg <strub...@yahoo.de> wrote: > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
