You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Robert Metzger (JIRA)" <ji...@apache.org> on 2017/05/31 12:38:11 UTC

[jira] [Updated] (FLINK-5513) Remove relocation of internal API classes

     [ https://issues.apache.org/jira/browse/FLINK-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Metzger updated FLINK-5513:
----------------------------------
    Fix Version/s:     (was: 1.3.0)
                   1.4.0

> Remove relocation of internal API classes
> -----------------------------------------
>
>                 Key: FLINK-5513
>                 URL: https://issues.apache.org/jira/browse/FLINK-5513
>             Project: Flink
>          Issue Type: Improvement
>          Components: Build System
>    Affects Versions: 1.2.0, 1.3.0
>            Reporter: Till Rohrmann
>             Fix For: 1.4.0
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)