Pulling curated code out of the test-jar is a worthwhile exercise for ourselves and downstream.

On 2/12/18 3:16 PM, Mike Drob wrote:
I think everybody has made valid points here.

I think what we want to do long term is rework test-util to be a curated
set of classes instead of a bunch of test-jars moved into compile
dependency scope. I'm not quite sure where to begin with this though, it
seems like a fairly substantial effort. I'll file some placeholder JIRAs
later with an eye toward 3.0


On Mon, Feb 12, 2018 at 1:55 PM, Andrew Purtell <apurt...@apache.org> wrote:

There is a good argument to be made about making the minicluster and
supporting classes LimitedPrivate or Public. And moving them to src/, IMHO,
because having public stuff in test/ is weird (but this might just be me).
I do not think making the testing utility classes Public makes sense. Our
internal testing scaffold is not a public API and never should be. Its what
we use to *test*. By definition this needs to evolve without concern paid
to downstreamers.

It could make sense to pull out a supportable subset, like we did for
HRegion -> Region and other aspects of coprocessor API for coprocessor

On Mon, Feb 12, 2018 at 10:23 AM, Josh Elser <els...@apache.org> wrote:


We have enough downstream projects that we *should* be providing
stable for people to use to a basic degree (perhaps not as crazy as some
the API we use for injecting faults). I think your suggestion, Duo, is a
nice step towards that.

Any attempt to tell folks to not use it will just trigger some
backlash/animosity (not trying to imply others suggested this -- just
stating to color my view).

On 2/11/18 9:18 PM, 张铎(Duo Zhang) wrote:

We also use HBTU to write UTs in our own code. But I agree that HBTU
not be public, instead, we can make MiniHBaseCluster public.

And maybe introduce a new scope of IA.LimitedPrivate, let's call it
'TESTING', which indicates that these classes are only used to write
do not use it in production, and we can mark it as IS.Evolving so that
could break the API between minor releases. I think this is OK as it is
only supposed to be used by UTs?


2018-02-04 1:34 GMT+08:00 Andrew Purtell <andrew.purt...@gmail.com>:

This has always been my opinion about this, but that doesn't make it a

On Feb 2, 2018, at 8:50 PM, Apekshit Sharma <a...@cloudera.com> wrote:

bq. Anything in test/ can't be public API by definition. Move it into


if that is desired.

If that has always been our stance, we should probably clarify it in
documentation. Or maybe it's already there and i missed it.
Didn't find anything searching for 'test' in

I see IA.Public annotations on follow classes under **/test/ path:
HBCommonTU, HBTU, MiniHBaseCluster, CodecPerformance, and

At least MiniHBaseCluster seems like it might be useful to downstream
projects. Others may have nuggets which might make sense in public
Not sure what's best though - moving the classes + declaration that
code is private, or letting annotations do they work as they do work

-- Appy

On Fri, Feb 2, 2018 at 5:56 PM, Andrew Purtell <apurt...@apache.org>


Phoenix is being a bit naughty. On the other hand, the status of this


isn't clear.

On Fri, Jan 26, 2018 at 2:10 PM, Ted Yu <yuzhih...@gmail.com> wrote:

At least Phoenix is using it.
If you search in Phoenix repo, you would see a lot of classes with:

import org.apache.hadoop.hbase.HBaseTestingUtility;

If you have specific method(s) which you consider changing, you can


On Fri, Jan 26, 2018 at 2:01 PM, Mike Drob <md...@apache.org>

Can we make changes between releases? Do we know who else is using


Best regards,

Words like orphans lost among the crosstalk, meaning torn from
decrepit hands
    - A23, Crosstalk


-- Appy

Best regards,

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
    - A23, Crosstalk

Reply via email to