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/
