[jira] [Commented] (HBASE-19114) Split out o.a.h.h.zookeeper from hbase-server and hbase-client

["Appy (JIRA)" <ji...@apache.org>]

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

Appy commented on HBASE-19114:
------------------------------

bq. I do not think people will like multi modules, for example, we always depend on netty-all instead of the individual netty modules right? The issue will also effect hbase-client so I’m a little nervous. I haven’t stopped the http module separation since it is server only

Indeed! That is a very valid point [~Apache9]!
Made me think, does netty really build everything as one module!? That would be one crazy codebase to maintain.
Looked for io.netty on central mvn repo (https://mvnrepository.com/artifact/io.netty), found ~40 artifacts associated with it. So probably netty-all is made by merging all of them together for convenience of users. It'd have been nightmare if we had to choose and pick individual jar ourselves, netty-all does makes like much simpler!

Am thinking if we can do similar - publish a hbase-all. That'd prevent breakages in downstream project like the recent ones in pig, hive, crunch, kite, etc when we split out hbase-mapreduce.
Admittedly, it'll be one big jar, but if it makes life of downstream projects easy, won't they really like it?

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