[
https://issues.apache.org/jira/browse/FLINK-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209424#comment-16209424
]
Chesnay Schepler commented on FLINK-5513:
-----------------------------------------
It isn't, since with FLINK-7779 the relocation is done ahead of time and not
when compiling Flink.
> 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.4.14#64029)
