Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Workaround
-
1.2.0, 1.3.0
-
None
-
None
Description
Currently, we are relocating the curator dependency in order to avoid conflicts with user code classes. This happens for example in the flink-runtime module. The problem with that is that curator classes, such as the CuratorFramework, are part of Flink's internal API. So for example, the ZooKeeperStateHandleStore requires a CuratorFramework as argument in order to instantiate it. By relocating curator it is no longer possible to use this class outside of flink-runtime without some nasty tricks (see flink-mesos for that).
I think it is not good practice to relocate internal API classes because it hinders easy code reuse. I propose to either introduce our own interfaces which abstract the CuratorFramework away or (imo the better solution) to get rid of the Curator relocation. The latter might entail that we properly separate the API modules from the runtime modules so that users don't have to pull in the runtime dependencies if they want to develop a Flink job.
Attachments
Issue Links
- Is contained by
-
FLINK-14177 Bump Curator From 2.12.0 to 4.2.0
- Closed
- is related to
-
FLINK-7995 Created curator/zk module in flink-shaded
- Closed
- is required by
-
FLINK-5508 Remove Mesos dynamic class loading
- Closed