Hi, Forget to mention, most changes are file renames between maven modules not java packages. That is moving `ZooKeeper` from module `zookeeper-server` to `zookeeper-client` but not from package `o.a.zookeeper` to `o.a.zookeeper.client`. So the result is not compatible with the java module system as far as I know.
Best, Kezhu Wang On Mon, Aug 25, 2025 at 1:18 AM Kezhu Wang <kez...@apache.org> wrote: > > 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
