[
https://issues.apache.org/jira/browse/HBASE-19114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16233546#comment-16233546
]
Appy commented on HBASE-19114:
------------------------------
But i'd still like to understand what was I missing!
bq. ...future hbase-client will only depend a small set of zk related code, so
it make no sense to have a module that only have one class right
It has all zk stuff, from both client and server. So even if client's stuff is
gone, server's requirements will remain there.
bq. But if in 2.0 you make hbase-client depend on an external hbase-zookeeper
module, then it is not a good idea to remove the dependency in 3.0. It is very
easy for a user to have a 3.0 hbase-client on the classpath and also a 2.0
hbase-zookeeper on the classpath.
Why won't it be easy to remove the dep? How's that worse than having
hbase-client 3.0 and hbase-common 2.0?
> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --------------------------------------------------------------
>
> Key: HBASE-19114
> URL: https://issues.apache.org/jira/browse/HBASE-19114
> Project: HBase
> Issue Type: Sub-task
> Reporter: Appy
> Assignee: Appy
> Priority: Major
> Attachments: HBASE-19114.master.001.patch,
> HBASE-19114.master.002.patch, HBASE-19114.master.003.patch,
> HBASE-19114.master.004.patch, HBASE-19114.master.005.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to
> hbase-server:o.a.h.h.master.
> - Move Abortable to hbase-common. Since it's IA.Private and independent of
> anything, moving it to hbase-common which is at bottom of the dependency tree
> is better.
> - Moved RecoveringRegionWatcher to hbase-server:o.a.h.h.regionserver
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.* to hbase-zookeeper module. We want to
> keep hbase-zookeeper very independent and hence at lowest levels in our
> dependency tree.
> - ZKUtil is a huge tangle since it's linked to almost everything in
> \[hbase-client/]oahh.zookeeper. And pulling it down requires some basic proto
> functions (mergeFrom, PBmagic, etc). So what i did was:
> ** Pulled down common and basic protobuf functions (which only depend on
> com.google.protobuf.\*) to hbase-common so other code depending on them can
> be pulled down if possible/wanted in future. This will help future dependency
> untangling too. These are ProtobufMagic and ProtobufHelpers.
> ** Didn't move any hbase-specific PB stuff to hbase-common. We can't pull
> things into hbase-common which add dependency between it and
> hbase-protobuf/hbase-shaded-protobuf since we very recently untangled them.
> - DEFAULT_REPLICA_ID is used in many places in ZK. Declared a new constant in
> HConstants (since it's in hbase-common) and using it in hbase-zookeeper.
> RegionInfo.DEFAULT_REPLICA_ID also takes its value from it to avoid case
> where two values can become different.
> - Renamed some classes to use a consistent naming for classes - ZK instead of
> mix of ZK, Zk , ZooKeeper. Couldn't rename following public classes:
> MiniZooKeeperCluster, ZooKeeperConnectionException.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
