Good call on all accounts! 1) I like the release plugin idea, just don't know anything about it.
2) I removed the incubator references and updated the site for SVN deploy. Here http://www.apache.org/dev/release.html under "How do I upload a release (newer way)?" describes the new deployment method. Brock On Fri, Sep 28, 2012 at 1:02 PM, Bertrand Dechoux <[email protected]> wrote: > I guess it has maybe already been tried but the maven release plugin is > good. But I wouldn't have now the time to verify if all the steps could be > done that way. Maybe for a future release? > > One trivial mistake : > Put in a Infrastructure JIRA > <https://issues.apache.org/jira/browse/INFRA> asking > to get added to the incubator unix group on people.apache.org and the > mrunit deployer roler for Nexus > > I guess the 'incubator' is not needed even though I have never opened an > infrastructure JIRA so I don't know if there is a different unix group for > graduated projects. > > Regards > > Bertrand > > On Fri, Sep 28, 2012 at 7:30 PM, Brock Noland <[email protected]> wrote: > >> OK, I have updated the release documents. >> http://mrunit.apache.org/pmc/how_to_release.html >> >> I think that should be correct, but anyone with a little git knowledge >> might want to double check. >> >> Brock >> >> On Thu, Sep 27, 2012 at 5:36 PM, James Kinley <[email protected]> wrote: >> > I can probably take a look at 111 next week, but I wouldn't want it to >> hold up Dave with the release. >> > >> > Thanks, James. >> > >> > On 27 Sep 2012, at 15:01, Jim Donofrio wrote: >> > >> >> When did you hope to cut a release candidate? >> >> >> >> We also need to go through the open tickets to see what can wait, Brock >> has MRUNIT-136 as a blocker. Sorry for not contributing in awhile but I >> need to fix some javadoc for 101,114,115. It would also be nice if someone >> did 111 for this release because we really should be using the release >> plugin, makes the whole process a lot easier. >> >> >> >> On 09/26/2012 11:45 AM, Brock Noland wrote: >> >>> OK that seems like a bargain! :) I'll work on updating the >> >>> instructions to what I think they should be (based on the experience >> >>> of the last few releases). >> >>> >> >>> Thanks! >> >>> Brock >> >>> >> >>> On Wed, Sep 26, 2012 at 10:42 AM, Dave Beech <[email protected]> >> wrote: >> >>>> The instructions also mention "incubator" quite heavily. I'd be happy >> >>>> to do the release (but only if the instructions get fixed first!!) >> >>>> >> >>>> On 26 September 2012 16:39, Brock Noland <[email protected]> wrote: >> >>>>> I suppose this will be the first release using git so the >> instructions >> >>>>> will have to be updated... >> >>>>> >> >>>>> On Wed, Sep 26, 2012 at 10:37 AM, Brock Noland <[email protected]> >> wrote: >> >>>>>> Hi, >> >>>>>> >> >>>>>> It's not a ton of work once you have done it, but the first time it >> >>>>>> can take some time. >> >>>>>> >> >>>>>> 1) Making sure we have the changes we said we would have in this >> release >> >>>>>> a) This release was contingent on a JIRA >> >>>>>> b) Ensuring the FIXED IN field in JIRA is correct >> >>>>>> 2) Executing the instructions here >> >>>>>> http://mrunit.apache.org/pmc/how_to_release.html >> >>>>>> >> >>>>>> Since we are a smaller project #1 is pretty easy. For projects like >> >>>>>> Hadoop #1 is a huge undertaking. For us, the real work is setting up >> >>>>>> your GPG keys and getting maven to deploy the jars correctly. >> >>>>>> Everything outside of environmental conditions *should* be >> documented >> >>>>>> in the release page. >> >>>>>> >> >>>>>> Since we are doing an incompatible change, we want to make sure the >> >>>>>> release notes reflect this. We also typically write a blog article >> >>>>>> (https://blogs.apache.org/mrunit/) and then ask Cloudera to >> re-post. >> >>>>>> In the past this has been about publicity for the project but this >> >>>>>> time it's probably a little more important due to the >> incompatibility. >> >>>>>> >> >>>>>> Brock >> >>>>>> >> >>>>>> On Wed, Sep 26, 2012 at 10:20 AM, Dave Beech <[email protected]> >> wrote: >> >>>>>>> Hi Brock - what's involved? I'm relatively new to the Apache >> process >> >>>>>>> but am willing to give it a go. >> >>>>>>> >> >>>>>>> Cheers, >> >>>>>>> Dave >> >>>>>>> >> >>>>>>> On 26 September 2012 16:18, Brock Noland <[email protected]> >> wrote: >> >>>>>>>> OK great, it sounds like the release is on! Does anyone want to >> be the >> >>>>>>>> Release Manager? I am more than willing to be the RM if no one >> else >> >>>>>>>> is interested, but as I have done it a few time times I won't >> feel too >> >>>>>>>> bad if someone else wants to. ;) >> >>>>>>>> >> >>>>>>>> Brock >> >>>>>>>> >> >>>>>>>> On Mon, Sep 24, 2012 at 7:28 AM, Jim Donofrio < >> [email protected]> wrote: >> >>>>>>>>> I wont -1 it but I wont +1 it either. I would rather save major >> revision >> >>>>>>>>> changes for more drastic api changes but we need to cut this >> release so I >> >>>>>>>>> wont get in the way. Lets cut a release candidate on Oct 1 as we >> talked >> >>>>>>>>> about before. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On 09/24/2012 04:55 AM, James Kinley wrote: >> >>>>>>>>>> +1 to major release with MRUNIT-138. >> >>>>>>>>>> >> >>>>>>>>>> James. >> >>>>>>>>>> >> >>>>>>>>>> On 24 Sep 2012, at 09:21, Dave Beech <[email protected]> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Hi Brock >> >>>>>>>>>>> Same here - I would be happy to see a major version release >> with >> >>>>>>>>>>> MRUNIT-138 included. >> >>>>>>>>>>> Cheers >> >>>>>>>>>>> Dave >> >>>>>>>>>>> >> >>>>>>>>>>> On 24 September 2012 07:35, Jarek Jarcec Cecho < >> [email protected]> wrote: >> >>>>>>>>>>>> Hi Brock, >> >>>>>>>>>>>> thank you for your summary. I'm fine with the idea and I >> won't -1 it. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Jarcec >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Sat, Sep 22, 2012 at 07:48:16AM -0500, Brock Noland wrote: >> >>>>>>>>>>>>> It feels like we approaching a consensus on that if we >> include >> >>>>>>>>>>>>> MRUNIT-138, which is backwards incompatible but an improved >> user API, >> >>>>>>>>>>>>> we should bump the major version. Assuming MRUNIT-138 is >> included, is >> >>>>>>>>>>>>> there anyone that would -1 a release with the 1.0 >> designation? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Brock >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Thu, Sep 13, 2012 at 11:42 AM, Brock Noland < >> [email protected]> >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>> I agree that the changes in this release are not nearly as >> substantial >> >>>>>>>>>>>>>> as handling the Tool interface but I do they are major >> improvements. >> >>>>>>>>>>>>>> For example, we now allow users to specify many input >> key/values and >> >>>>>>>>>>>>>> have distributed cache support. For quick reference: >> >>>>>>>>>>>>>> http://s.apache.org/NQY >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Brock >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> On Thu, Sep 13, 2012 at 8:16 AM, Jim Donofrio < >> [email protected]> >> >>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>> Yes graduation has nothing to do with the quality or state >> of the >> >>>>>>>>>>>>>>> code, >> >>>>>>>>>>>>>>> graduation is all about community and should not influence >> a release >> >>>>>>>>>>>>>>> number. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> I agree that 1.0 would signal a breaking change but 1.0 >> should also >> >>>>>>>>>>>>>>> signal >> >>>>>>>>>>>>>>> major improvements, api changes, new features. I dont >> think this >> >>>>>>>>>>>>>>> release >> >>>>>>>>>>>>>>> contains any drastic features. I think we should continue >> in the 0.* >> >>>>>>>>>>>>>>> versions for awhile until we add major new features such >> as Tool >> >>>>>>>>>>>>>>> support. At >> >>>>>>>>>>>>>>> that time you can change the package names to >> org.apache.mrunit and >> >>>>>>>>>>>>>>> go to >> >>>>>>>>>>>>>>> 1.0. I would rather not become like Firefox or Chrome and >> do major >> >>>>>>>>>>>>>>> release >> >>>>>>>>>>>>>>> number changes on every release. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On 09/13/2012 06:31 AM, Jarek Jarcec Cecho wrote: >> >>>>>>>>>>>>>>>> I do have similar reasoning here: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> 1.0 - in case that we're breaking backward compatibility >> >>>>>>>>>>>>>>>> 0.10 - in case that we're not breaking backward >> compatibility >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> I personally do not see graduation of the project >> important enough >> >>>>>>>>>>>>>>>> for the >> >>>>>>>>>>>>>>>> version to jump to next major. We've recently graduated >> sqoop and >> >>>>>>>>>>>>>>>> flume and >> >>>>>>>>>>>>>>>> remained on the same major version without any issues. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> But I'll support next reason no matter the final version. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Jarcec >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> On Wed, Sep 12, 2012 at 11:41:08PM +0200, Bertrand >> Dechoux wrote: >> >>>>>>>>>>>>>>>>> And I would say the same in a reverse way. >> >>>>>>>>>>>>>>>>> If we do a 1.0 release, all required incompatible >> changes should be >> >>>>>>>>>>>>>>>>> done >> >>>>>>>>>>>>>>>>> so >> >>>>>>>>>>>>>>>>> that there would be no need to drag unneeded deprecated >> stuff from >> >>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> 1.0 >> >>>>>>>>>>>>>>>>> up to the 2.0. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> For me, the question is whether we should break >> compatibility for >> >>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> next >> >>>>>>>>>>>>>>>>> release. If yes, then break all which is necessary for a >> clean >> >>>>>>>>>>>>>>>>> future. If >> >>>>>>>>>>>>>>>>> not, then assure full compatibility. If yes, it should >> be 1.0. If >> >>>>>>>>>>>>>>>>> not, it >> >>>>>>>>>>>>>>>>> should be 0.10. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> The following question is then : if we keep >> compatibility what will >> >>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> next release ship with? Is a release worth the new >> features/bug >> >>>>>>>>>>>>>>>>> fixes? On >> >>>>>>>>>>>>>>>>> that point, I am not knowledgeable enough to answer. I >> would accept >> >>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> decisions of the more 'ancient' devs. But it should >> indeed be >> >>>>>>>>>>>>>>>>> discussed. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Regards, >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Bertrand >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> On Wed, Sep 12, 2012 at 9:05 PM, Wei, Jianbin < >> [email protected]> >> >>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> If it is an incompatible change in non-trivial way, I >> would strong >> >>>>>>>>>>>>>>>>>> in >> >>>>>>>>>>>>>>>>>> favor a 1.0 release. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Regards, >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -- Jianbin >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On Sep 12, 2012, at 10:01 AM, Brock Noland wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> OK, we have the following viewpoints with supporting >> reasons: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 0.10 - supported by a number of people (reasons: none >> given, 1.0 >> >>>>>>>>>>>>>>>>>> should be used for Tool interface support) >> >>>>>>>>>>>>>>>>>> 1.0 - supported by a number of people (reasons: none >> given, recent >> >>>>>>>>>>>>>>>>>> graduation, due to the incompatible change) >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> I tilt towards the 1.0 release due to the incompatible >> changes but >> >>>>>>>>>>>>>>>>>> I >> >>>>>>>>>>>>>>>>>> am not strongly committed to that viewpoint. I am >> strongly >> >>>>>>>>>>>>>>>>>> committed >> >>>>>>>>>>>>>>>>>> to a release whatever the number! :) It would seem easy >> enough to >> >>>>>>>>>>>>>>>>>> vote >> >>>>>>>>>>>>>>>>>> on the matter but I think votes can become divisive. I >> have seen >> >>>>>>>>>>>>>>>>>> that >> >>>>>>>>>>>>>>>>>> in the Hadoop community when voting is used to resolve >> issues it >> >>>>>>>>>>>>>>>>>> ends >> >>>>>>>>>>>>>>>>>> up much like the state of US politics. As such, I'd >> prefer to >> >>>>>>>>>>>>>>>>>> settle >> >>>>>>>>>>>>>>>>>> this via discussion. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> We have all stated our preferences but not our >> convictions. Is >> >>>>>>>>>>>>>>>>>> there >> >>>>>>>>>>>>>>>>>> anyone who strongly in favor of / opposed to a 0.10 >> release? Is >> >>>>>>>>>>>>>>>>>> there >> >>>>>>>>>>>>>>>>>> anyone who is strongly in favor of / opposed to a 1.0 >> release? If >> >>>>>>>>>>>>>>>>>> so >> >>>>>>>>>>>>>>>>>> please state your reasoning. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Brock >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On Fri, Sep 7, 2012 at 11:50 AM, Wei, Jianbin >> >>>>>>>>>>>>>>>>>> <[email protected]<mailto: >> >>>>>>>>>>>>>>>>>> [email protected]>> wrote: >> >>>>>>>>>>>>>>>>>> Agree with Dave that when it becomes incompatible, the >> major >> >>>>>>>>>>>>>>>>>> version >> >>>>>>>>>>>>>>>>>> number should be increased. Major changes also warrant >> a major >> >>>>>>>>>>>>>>>>>> number >> >>>>>>>>>>>>>>>>>> change. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Regards, >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -- Jianbin >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On Sep 7, 2012, at 8:06 AM, Brock Noland wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> As I understand it, if we implement >> >>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MRUNIT-138 as >> described in >> >>>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>>> JIRA. That is, all the drivers keep state of the >> inputs, we can >> >>>>>>>>>>>>>>>>>> undeprecate the methods depcrecated in >> >>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MRUNIT-64? >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Brock >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On Fri, Sep 7, 2012 at 7:58 AM, Jim Donofrio >> >>>>>>>>>>>>>>>>>> <[email protected] >> >>>>>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: >> >>>>>>>>>>>>>>>>>> I think we need to keep those deprecated methods around >> for >> >>>>>>>>>>>>>>>>>> awhile, no >> >>>>>>>>>>>>>>>>>> reason to anger users. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On 09/07/2012 08:35 AM, Bertrand Dechoux wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Then the question is about when/if the compatibility >> should be >> >>>>>>>>>>>>>>>>>> broken. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MRUNIT-139 would >> be quite >> >>>>>>>>>>>>>>>>>> easy >> >>>>>>>>>>>>>>>>>> without the history of MRUnit and the @Deprecated.... >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On Fri, Sep 7, 2012 at 2:19 PM, Dave Beech >> >>>>>>>>>>>>>>>>>> <[email protected]<mailto: >> >>>>>>>>>>>>>>>>>> [email protected]>> wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> I think this depends on what we decide to do about >> MRUNIT-138. We >> >>>>>>>>>>>>>>>>>> were >> >>>>>>>>>>>>>>>>>> discussing an incompatible change, and if we do decide >> to do that >> >>>>>>>>>>>>>>>>>> I >> >>>>>>>>>>>>>>>>>> think >> >>>>>>>>>>>>>>>>>> the version number should increase to 1.0.0 to reflect >> this (and >> >>>>>>>>>>>>>>>>>> also >> >>>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>>> fact that this is the first version since graduation). >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> If we later go ahead with the API rewrite (MRUNIT-69), >> this could >> >>>>>>>>>>>>>>>>>> form >> >>>>>>>>>>>>>>>>>> MRUnit 2.0.0! Would line up nicely with Hadoop's own >> numbering >> >>>>>>>>>>>>>>>>>> strategy >> >>>>>>>>>>>>>>>>>> ;) >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On 7 September 2012 07:54, James Kinley >> >>>>>>>>>>>>>>>>>> <[email protected]<mailto: >> >>>>>>>>>>>>>>>>>> [email protected]>> wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> +1 for the 1.0.0 release. I think it's a good idea to >> increase the >> >>>>>>>>>>>>>>>>>> major >> >>>>>>>>>>>>>>>>>> version number considering the recent graduation and >> the included >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> changes. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On 7 Sep 2012, at 07:29, "Wei, Jianbin" >> >>>>>>>>>>>>>>>>>> <[email protected]<mailto: >> >>>>>>>>>>>>>>>>>> [email protected]>> wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> My bad, 0.9.0 --> 0.10.0 is also version increase. My >> eyes are >> >>>>>>>>>>>>>>>>>> not >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> used >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> to have a 2 digits minor version yet. However, I still >> prefer a >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> one-digit >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> minor version as most software do that in practice. >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Regards, >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -- Jianbin >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On Sep 6, 2012, at 10:41 PM, Bertrand Dechoux wrote: >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> I am not sure to understand "It is not good to >> backtracking >> >>>>>>>>>>>>>>>>>> version.". >> >>>>>>>>>>>>>>>>>> Does it mean that the version after graduating should >> show the >> >>>>>>>>>>>>>>>>>> 'step'? >> >>>>>>>>>>>>>>>>>> Is that a common way to do it? >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Not taking into account the graduation, I would also >> favor the >> >>>>>>>>>>>>>>>>>> "0.10.0" >> >>>>>>>>>>>>>>>>>> instead of "1.0.0". >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Regards >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Bertrand >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>>> Apache MRUnit - Unit testing MapReduce - >> >>>>>>>>>>>>>>>>>> http://incubator.apache.org/mrunit/ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>>> Apache MRUnit - Unit testing MapReduce - >> >>>>>>>>>>>>>>>>>> http://incubator.apache.org/mrunit/ >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>> Bertrand Dechoux >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>> Apache MRUnit - Unit testing MapReduce - >> >>>>>>>>>>>>>> http://incubator.apache.org/mrunit/ >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> -- >> >>>>>>>>>>>>> Apache MRUnit - Unit testing MapReduce - >> >>>>>>>>>>>>> http://incubator.apache.org/mrunit/ >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Apache MRUnit - Unit testing MapReduce - >> http://incubator.apache.org/mrunit/ >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Apache MRUnit - Unit testing MapReduce - >> http://incubator.apache.org/mrunit/ >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Apache MRUnit - Unit testing MapReduce - >> http://incubator.apache.org/mrunit/ >> >>> >> >>> >> >> >> > >> >> >> >> -- >> Apache MRUnit - Unit testing MapReduce - >> http://incubator.apache.org/mrunit/ >> > > > > -- > Bertrand Dechoux -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
