Hi all, I have put effort into separating `zookeeper-client` and more from `zookeeper` to ship ZOOKEEPER-233[1].
I start this discussion to share my progress and want to reach a community wide consensus on some directions. In the process of this, I found that `QuorumPeerConfig.ConfigException` was thrown from `ZKConfig` and reported it as ZOOKEEPER-4966[2]. It is impossible to split client classes out of server code without breaking things as `QuorumPeerConfig` is tied to `QuorumPeer` which is tied to massive other server codes. I propose to introduce superclass `o.a.zookeeper.common.ConfigException` for `QuorumPeerConfig.ConfigException`, and opened pr-2309[3] and pr-2306[4] for current and next releases. pr-2309[3] introduces new methods to throw `o.a.zookeeper.common.ConfigException` and deprecates old ones. pr-2306[4] changes old methods to throw the new exception class also, so it is a breaking change in source code level , it does keep abi compatibility. Based on the above, I drafted pr-2307[5] to split `zookeeper-client` from `zookeeper`, and `zookeeper-common`, `zookeeper-server`, `zookeeper-cli` further more in my fork[6]. The current situation is that: 1. The old `zookeeper` could be splitted to `zookeeper-common`, `zookeeper-client`, `zookeeper-server`, `zookeeper-cli` and also `zookeeper`. 2. `zookeeper` is a bundle package for both deployment and osgi just as before. 3. `zookeeper-server` depends only on `zookeeper-client` for tests. 4. `zookeeper-cli` depends on `zookeeper-server` for `QuorumPeerConfig` in `ReconfigCommand`. 5. `zookeeper-server` still contains command line tools such as `TxnLogToolkit`, `LogChopper`, `SnapshotComparer`, `SnapshotFormatter` and more. 6. Most tests still reside in `zookeeper-server` since they are relying on server connection, some may not but depend on `ClientBase`. 7. Given above, most client sides have to reside in `zookeeper-server` for now as maven forbid cycle dependency for tests. 8. `test-jar` is broken. Dependants should migrate themselves from `zookeeper` to `zookeeper-server`. Given all above, I want to know is it ok to ship with this many jars ? or the community wants few ? Also, there are discussions[7][8] to bump the jdk version in the next feature release, I think this would help to keep `zookeeper-client` to a lower jdk version compared to server side deployment just as what kafka[9] and pulsar do. [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-233 [2]: https://issues.apache.org/jira/browse/ZOOKEEPER-4966 [3]: https://github.com/apache/zookeeper/pull/2309 [4]: https://github.com/apache/zookeeper/pull/2306 [5]: https://github.com/apache/zookeeper/pull/2307 [6]: https://github.com/kezhuw/zookeeper/commits/ZOOKEEPER-233-split-server-jar/ [7]: https://lists.apache.org/thread/5oqm5r8jyj8w3j06ckbnbcgdt8hp3hrn [8]: https://lists.apache.org/thread/42537mr70g3n8srzxg406xlssbcsqr7w [9]: https://kafka.apache.org/40/documentation/compatibility.html [10]: https://github.com/apache/pulsar?tab=readme-ov-file#pulsar-runtime-java-version-recommendation
