[
https://issues.apache.org/jira/browse/HBASE-19114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16232593#comment-16232593
]
Duo Zhang commented on HBASE-19114:
-----------------------------------
Then if someone depends netty-all while others depend the individual netty
modules, it will be totally a mess. That's one of the reasons why we want to
shade netty to prevent breaks downstream users, and also prevent us being
broken by hadoop.
Can we delay this for a while? Is it necessary for 2.0 release? As I said
above, in the 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? 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. It is annoying.
For me, I would like this:
1. Move ZNodePaths to hbase-common, and also a very very small ZKUtil which
only have a very very small set of helper methods, such as removing the prefix.
hbase-common will not depend on zk.
2. hbase-client will implement the zk logic by its own with curator, no
external dependency.
3. Introduce a hbase-zookeeper module which implements all the zk related logic
for hbase-server, and make hbase-server depend on it to make hbase-server less
complex.
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)
