[ 
https://issues.apache.org/jira/browse/HBASE-19114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16233562#comment-16233562
 ] 

Duo Zhang commented on HBASE-19114:
-----------------------------------

{quote}
It has all zk stuff, from both client and server. So even if client's stuff is 
gone, server's requirements will remain there.
{quote}
In general I would like hbase-client only depends on the stuffs which are only 
used by client, not server, so we may have two zk modules and after the 
purging, the module for client will only have one or two classes.

For hbase-common conflict, it is easier to address as user can just declare a 
3.0 dependency in the pom to force a 3.0 hbase-common on classpath. But for 
hbase-zk, you need to find out who introduce it and exclude it there, and maybe 
there are lots of them... Anyway, there are lots of maven magics so the problem 
can be addressed, no doubt. But I think we'd better not add more magics.

The zk stuffs in hbase-client is mainly used by sync client, the old plan is to 
replace the sync client implementation with async client in 3.0. Now if you 
really want the zk split in 2.0, then I think we could purge the zk stuff first 
for sync client in 2.0.

Thanks.

> 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)

Reply via email to