[
https://issues.apache.org/jira/browse/HBASE-13126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355785#comment-17355785
]
Sean Busbey commented on HBASE-13126:
-------------------------------------
thinking about this more, that approach will force all downstream users to
adapt to a bunch of breaking changes. Could we instead flip this around a bit
to minimize the downstream impact:
* move HBTU into the module
* make a new parent class to HBTU that lives in hbase-server still and has the
implementation logic, e.g. {{InternalHBaseTestingUtiltiy}}, and make this class
private
* Move our hbase-server tests to use the new {{InternalHBaseTestUtility}}
* Deprecate and start removing from HBTU stuff that we only want for internals
This way downstream folks *maybe* have to change a dependency if they were
directly relying on hbase-server's test jar instead of hbase-testing-utility
for some reaosn, but otherwise they can happily go on.
> Provide alternate mini cluster classes other than HBTU for downstream users
> to write unit tests
> -----------------------------------------------------------------------------------------------
>
> Key: HBASE-13126
> URL: https://issues.apache.org/jira/browse/HBASE-13126
> Project: HBase
> Issue Type: Umbrella
> Components: API
> Affects Versions: 2.0.0
> Reporter: Sean Busbey
> Priority: Critical
> Fix For: 3.0.0-alpha-2
>
>
> Over in the review for HBASE-12972, [~enis] mentioned that one of the HBTU
> methods wasn't intended for public consumption.
> Can we build a list of such methods across the API, appropriately annotate
> them for 2.0, and deprecate them in earlier versions with a warning that
> they're going to be restricted?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
