incubator-crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Wills (JIRA)" <>
Subject [jira] [Commented] (CRUNCH-60) Splitting the core crunch module
Date Mon, 10 Sep 2012 09:34:07 GMT


Josh Wills commented on CRUNCH-60:

I think that from a code organization perspective, it makes sense, with nothing depending
on -api, and it would be ideal for -impl to be independent of common/lib, although that wouldn't
work right now (e.g., mapside joins.) I think the first step in this direction would be adding
API methods that would make that independence feasible.

-io could be its own component that is independent of the -impl and common/lib modules, me

My only strong objection would be putting o.a.crunch.test into src/test/java, since it's designed
to be used by clients who are writing unit tests and I'm against having dependencies on test-jar
targets. common/lib makes the most sense logically.
> Splitting the core crunch module
> --------------------------------
>                 Key: CRUNCH-60
>                 URL:
>             Project: Crunch
>          Issue Type: Bug
>            Reporter: Vinod Kumar Vavilapalli
> It looks like the api is interspersed with the implementation details and libraries/utils
a bit. How about:
>  - An api module which only has the APIs that users need to code against
>   -- Most of org.apache.crunch
>   --  org.apache.crunch.types.*
>  - A common/lib module
>   -- package org.apache.crunch.fn
>   -- some stuff like MapFn, FilterFn from org.apache.crunch package
>   -- All of org.apache.crunch.lib.* that is not included in the other modules above and
>   -- org.apache.crunch.util
>   -- org.apache.crunch.tool
>  - A crunch-impl module where the rest of it resides.
>   -- All of *impl* packages
>   -- org.apache.crunch.hadoop.mapreduce.lib.jobcontrol
>   -- org.apache.crunch.hadoop.mapreduce.lib.output
>   -- org.apache.crunch.materialize?
> Also move org.apache.crunch.test to src/test/java.
> Need help on placing* correctly.
> Note that despite all this, if necessary, we can choose to have a single artifact (jars
etc) to avoid users the onus of importing multiple modules.
> Thoughts?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message