hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom White (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MAPREDUCE-1638) Divide MapReduce into API and implementation source trees
Date Tue, 30 Mar 2010 23:12:27 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851653#action_12851653

Tom White commented on MAPREDUCE-1638:

bq. After considering it, I don't think that we should separate the api from the impls. In
general, that makes more sense if you have multiple implementations of the api.

In some sense we already have multiple implementations of the API, if you consider the full
distributed implementation and LocalJobRunner as different implementations. (Also MRUnit is
a partial implementation.)

bq. I'm also worried that there would be a circular dependence between the two jars.

You're right that there are currently many circular dependencies, which are hard to break.
Perhaps we can improve this in the future, but it's a bigger project (a project Jigsaw - http://openjdk.java.net/projects/jigsaw/
- for MapReduce?). 

bq. I agree that we need to make the line stronger, but maybe it would be better to move the
implementations into new packages?

This would be a good step. For the moment, I think that a combination of MAPREDUCE-1623 and
HADOOP-6658 is enough to define the public user-facing API. 

> Divide MapReduce into API and implementation source trees
> ---------------------------------------------------------
>                 Key: MAPREDUCE-1638
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-1638
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: build, client
>            Reporter: Tom White
>            Assignee: Tom White
> I think it makes sense to separate the MapReduce source into public API and implementation
trees. The public API could be broken further into kernel and library trees.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message