[
https://issues.apache.org/jira/browse/HBASE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971964#action_12971964
]
stack commented on HBASE-3361:
------------------------------
ivy is an abomination. ant is too but everyone is doing it (smile).
You reminded me that hadoop build mess is ant+ivy-based. I forgot for a second.
On 1. above, "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." strikes me as
artificial and difficult to uphold. 2. sounds better.
3. is what we used to have (If you dig back in history, you'll trip over it).
But truth be told, I don't like 1., 2., or 3. I want our layout to be as it is
currently but sounds like maven would force us have another.
In maven, for one module only projects, the produced jar usually includes tests
or not?
Do you think downstream folks want tests + testing facility like
HBaseTestingUtility or do they just need the latter? If so, then what about a
refactor to add those items from src/test into our produced jar and no
hbase-test?
Just exploring options. Thanks Ed.
> 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.
