hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Kohlwey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3361) Modularize Maven Structure for Tests
Date Thu, 16 Dec 2010 01:51:01 GMT

    [ https://issues.apache.org/jira/browse/HBASE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971934#action_12971934
] 

Ed Kohlwey commented on HBASE-3361:
-----------------------------------

Can you clarify your question about Hadoop? They do have a separate package in central that
they put their integration testing utilities in (called org.apache.hadoop.hadoop-test), so
from an end user perspective its the same.

>From the hadoop/hbase developers perspective, it isn't the same, but they're using a completely
different build tool (ivy + ant) that doesn't really have the same notion of multi-module
builds, so its sort of apples and oranges. By using maven, HBase is sacrificing some of the
flexibility that comes from a very free-form build tool like ant, and trading it for less
configuration. Hadoop's build scripts are (IMHO) quite complicated.

There should probably be some discussion of how to split tests. In my view there's three options:
1. What I currently have in github: a test module and hbase module. The hbase module has unit
tests (tests that don't require a "live" cluster to be running) and the test module includes
integration testing utilities that it publishes as artifacts, and its OWN tests are the integration
tests. I like this because its just not very many modules.
2. Same as above but move all tests into the test module. I guess this is ok too, but I feel
like it might encourage to develop in the hbase module without running any tests, which might
not be the right thing.
3. Have three modules: the core, the one that is used to publish testing utilities as an artifact,
and one that actually has the tests. IMHO at this point you're getting to the point of excessive
complication.

> Modularize Maven Structure for Tests
> ------------------------------------
>
>                 Key: HBASE-3361
>                 URL: https://issues.apache.org/jira/browse/HBASE-3361
>             Project: HBase
>          Issue Type: Improvement
>          Components: test
>            Reporter: Ed Kohlwey
>            Assignee: Ed Kohlwey
>
> There's a few reasons to break tests out into their own module:
> 1. Allowing maven users to easily re-consume test utilities as part of a "test" package
which doesn't pollute the runtime classpath
> 2. Putting integration tests (tests that create or require a cluster) in their own module
allows users to easily rebuild and test the core of HBase without running long-running tests,
reducing the developer iteration loop
> After some discussions with Stack on IRC, it sounds like there was some historic investigation
of this which was abandoned because the module system was becoming too complex. I'd suggest
that rather than trying to break out components all at once into their modules, evaluate creation
of modules on a case-by-case basis and only create them when there's a significant use case
justification.
> I created a sample of what I'm thinking about (based on the current trunk) and posted
it on github
> git://github.com/ekohlwey/modularized-hbase.git

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


Mime
View raw message