[ https://issues.apache.org/jira/browse/HBASE-26158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392269#comment-17392269 ]
Geoffrey Jacoby commented on HBASE-26158: ----------------------------------------- A correction: the Kafka minicluster in my example above is using the Kafka EmbeddedZookeeper class and not sharing a ZK quorum with the HBase minicluster or custom process. (Which do share with each other) So let's ignore it for this discussion. The reason why we can't use curator-test is that there's no way I can see to inject HBaseTestingUtility with a curator-test TestingServer instead of an MiniZookeeperCluster. So we have to inject a MiniZookeeperCluster into the custom process's in-process test harness. The test just wouldn't work with curator-test. (There _definitely_ isn't a way to do it with the TestingHBaseCluster, which is one of many reasons I proposed HBASE-26115.) HBase didn't have a "duty" to make MiniZookeeperCluster -- it could use curator-test internally and allow tests to inject a TestingServer in the HBTU -- but it did, and deliberately exposed it as IA.Public, and downstream users are allowed to rely on that. It _is_ literally designed to allow end users the ability to start a ZK to write UT. That's what IA.Public means. :-) > MiniZooKeeperCluster should not be IA.Public > -------------------------------------------- > > Key: HBASE-26158 > URL: https://issues.apache.org/jira/browse/HBASE-26158 > Project: HBase > Issue Type: Sub-task > Components: API, test > Reporter: Duo Zhang > Priority: Major > > End users do not need to test HBase when zookeeper is broken. And if users > want to start only a zookeeper cluster, they can just use curator-test, so I > do not think we should expose this class as IA.Public. -- This message was sent by Atlassian Jira (v8.3.4#803005)