StephanEwen edited a comment on issue #11173: [FLINK-13417][build] Bundle Zookeeper 3.5 in opt URL: https://github.com/apache/flink/pull/11173#issuecomment-590084670 I see. I guess under the current setup, that approach is fair enough. It would be nice to keep working on a bit better encapsulation, because the missing encapsulation contributes to the increasing "unwieldyness" of the build system. Concretely, for the ZK / Curator case: Why is that needed in 6 modules? Should it not be only needed in `flink-runtime` for our HA Services? If the same version/dependency is used in `flink-mesos`, don't we implicitly require that the Mesos ZK and the Flink HA ZK are the same version? In a clean setup, I would imagine that we have - a `flink-ha-services` module with the HA Services abstraction - two different sub-modules for ZK 3.4 (`flink-ha-services-zk-3_4`) and ZK 3.5 (`flink-ha-services-zk-3_5`), with the code and the tests. - Maybe most of the code/tests is taken from a shared `flink-ha-services-zk-base` module. - Each module does its tests for the ZK HA integration. No dependency change needed in any other module to test cross versions. - Possibly one end-2-end tests per version, but those should work "like users" meaning taking the relevant jar from the `/opt` folder. - In that approach, we also have the flexibility to implement the operations differently in different versions, like using "container" nodes in ZK 3.5, transactions, etc.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
