>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].
Well, the incremental work is not yet finished. And even if the maven-compiler-plugin works a bit to eagerly today this is much less of a problem than the previous behaviour where it didn't properly detect changes and just did not compile at all, creating broken jars, wars, ears, etc if you did not do a full clean upfront... We added a few ITs for it, but obviously not enough. Hope those additional changes are also backed by ITs. LieGrue, strub >________________________________ > From: Jason van Zyl <[email protected]> >To: Maven Developers List <[email protected]>; Mark Struberg ><[email protected]> >Sent: Saturday, December 8, 2012 6:22 PM >Subject: Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0 > > >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 <[email protected]> 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 <[email protected]> >>>To: Maven Developers List <[email protected]>; Mark Struberg >>><[email protected]> >>>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 <[email protected]> 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 <[email protected]> >>>>>To: Maven Developers List <[email protected]> >>>>>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 >>>>><[email protected]> >>> >>>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 >>>>>><[email protected]> >>> >>>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 <[email protected]> >>>>>>> > To: Maven Developers List <[email protected]> >>>>>>> > 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 >>>>>>> <[email protected]> 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 >>>>>>> <[email protected]> >>>>> >>>>> >>> To: Maven Developers List >>>>>>><[email protected]>; >>> >>>Mark Struberg >>>>> >>>>> > <[email protected]> >>>>>>> >>> 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 >>>>>>><[email protected]> >>> >>> >>>>> To: Maven Developers List >>>>>>> <[email protected]> >>>>> >>>>> >>>>> 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 >>>>> >>>>> >>>>> <[email protected]> >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> > > On Thu, Nov 29, 2012 at >>>>>>>11:05 PM, >>> >>>Jason van Zyl >>>>> >>>>> >>>>> <[email protected]> >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> > > > On Nov 29, 2012, at >>>>>>>5:56 PM, >>> >>>Benson >>>>> >>>>> > Margulies >>>>>>> >>>>> <[email protected] >>>>>>> >>>>>> > >>>>>>> >>>>>> > > >>>>>>> >>>>>> > > 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: >>>>>>>[email protected] >>> >>> >> For additional commands, e-mail: >>>>>>>[email protected] >>> >>> >> >>>>>>> > >>>>>>> > -- >>>>>>> > Daniel Kulp >>>>>>> > [email protected] - http://dankulp.com/blog >>>>>>> > Talend Community Coder - http://coders.talend.com >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> --------------------------------------------------------------------- >>>>> >>>>> > To unsubscribe, e-mail: [email protected] >>>>>>> > For additional commands, e-mail: >>>>>>>[email protected] >>> >>> > >>>>>>> >>>>>>> >>>>>>>--------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: [email protected] | [email protected] >>>>>> 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: [email protected] >>>>>For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: [email protected] >>>>For additional commands, e-mail: [email protected] >>>> >>>> >>> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [email protected] >>For additional commands, e-mail: [email protected] >> >> > >Thanks, > >Jason > >---------------------------------------------------------- >Jason van Zyl >Founder & CTO, Sonatype >Founder, Apache Maven >http://twitter.com/jvanzyl >--------------------------------------------------------- > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
