Hey Kishore, 1. How we will achieve this is still an area to explore. What was meant by the description is that it will allow for the possibility - basically, if we were to achieve that, it's a lot easier to reason about if we have two different modules as opposed to some package in the same module. Creating separate releases might be one option. 2. That is correct. But Helix's ZkClient has some additional connectors to make it easier to emit MBean metrics via JMX, and this is a common use case in a few different production settings (e.g. LinkedIn, Uber, etc.). So there is value in using Helix's ZooKeeper API if that fits users' use case better.
The new modules have been created in a pull request: zookeeper-api and helix-common. It is currently under review, and all Maven-based unit/integration tests came back green. Just moving files into a separate package is a trivial exercise, so upon discussing with a few of the PMC members/committers, I decided to go ahead with creating new modules. Care has been taken to move as little as possible, meaning the classes that were moved are bare minimum, and most of them have been left as a deprecated link (by way of subclassing) in helix-core to maintain as much backward-compatibility as possible. I am creating a more detailed and thorough test plan while the PR is being reviewed. Hunter On Thu, Jan 23, 2020 at 5:58 PM kishore g <[email protected]> wrote: > I like the idea of removing the dependency on zkclient but have few > questions on the approach. > > "This will allow for more modularity and remove deployment cadence > dependency among ZK-related classes and helix-core classes. Additionally, > those who wish to use Helix's ZK-related features without explicitly using > helix-core or Task Framework could do so by simply importing zookeeper-api > module." > > - How can we achieve this? Are we planning to make release these modules > independent of each other. > - Users should use Curator if they want ZK related features (make it easy > to use ZK) Helix has a different goal (making it easy to build distributed > systems). > > - Why not just pull the code into a separate package within helix-core as > the first step and think of moving it to a separate module at a later time. > > Thanks > Kishore G > > On Thu, Jan 23, 2020 at 5:38 PM Hunter Lee <[email protected]> wrote: > >> I added a short wiki describing this in GitHub: >> https://github.com/apache/helix/wiki/New-Modules-for-Apache-Helix >> >> >> On Tue, Jan 21, 2020 at 2:45 PM Hunter Lee <[email protected]> wrote: >> >>> It seems that it would be beneficial to separate ZkClient and its >>> supporting classes from IOItec into a separate module. This work includes >>> doing away with IOItec library altogether. We've made some bug fixes to >>> their implementation and noticed that some of their newer versions aren't >>> backward-compatible. >>> >>> This may require an addition of another module, say helix-common, to >>> resolve circular dependencies among the existing modules. >>> >>> This will allow for more modularity and remove deployment cadence >>> dependency among ZK-related classes and helix-core classes. Additionally, >>> those who wish to use Helix's ZK-related features without explicitly using >>> helix-core or Task Framework could do so by simply importing zookeeper-api >>> module. >>> >>> I'll be starting this work in a PR and let me know if you have any >>> feedback! >>> >>> Hunter >>> >>
