In my opinion, the ideal approach to mitigating conflicts between application code and Flink itself is to relocate all of Flink's dependencies. Rationale is to avoid placing the burden of relocation on the app developer, and ultimately to eliminate the need for an app uber-jar.
For example, imagine enhancing Flink to directly support Maven repositories, e.g. ``` $ flink run --package org.example:app:1.0 ... Downloading: https://repo1.maven.org/maven2/org/example/app/1.0/app.pom ... ``` >From that perspective, FLINK-6529 is another good step in that direction. But it seems like we'd be forking more libraries ("fetty"!). Would we need to alter the source code or rely on the shading plugin? As Chesnay mentioned, what's the impact in the IDE? In the future, could the entire flink-runtime be made an uber-jar, performing the relocation at that stage? On Thu, May 11, 2017 at 3:36 AM, Ufuk Celebi <u...@apache.org> wrote: > On Thu, May 11, 2017 at 10:59 AM, Till Rohrmann <trohrm...@apache.org> > wrote: > > Have we somewhere documented how to publish > > artifacts on Maven central? > > Pulling in Robert who published frocks. @Robert: Would you like to > volunteer for this? Would really help to combine this with some docs > about publishing Maven artefacts in the flink-shaded-deps README. :-) > In general, I'm curious to hear your opinion on this proposal. > > – Ufuk >
