Github user StephanEwen commented on the issue:
https://github.com/apache/flink/pull/5303
I would suggest to start thinking about the dependencies the following way:
- There are pure user-code projects where the Flink runtime is "provided"
and they are started using an existing Flink setup (`bin/flink run` or REST
entry point). This is the **Framework Style**.
- In the future, we will have "Flink as a Library" deployments, where
users add something like `flink-dist` as a library to their program and then
simply dockerize that Java application.
- Code can be run in the IDE or other similar style embedded forms. This
is in some sense also a "Flink as a Library" deployment, but with selective
(fewer) dependencies. The RocksDB issue applies only to this problem here.
To make this simpler for the users, it would be great to have not N
different models that we talk about, but ideally only two: **Framework Style**
and **Library Style**. We could for example start to advocate and document that
users should always use `flink-dist` as their standard dependency - "provided"
in the framework style deployment, "compile" in the library style deployment.
That might be a really easy way to work with that. The only problem for the
time being is that `flink-dist` is quite big and contains for example also
optional dependencies like `flink-table`, which makes it more hwavyweight for
quickstarts. Maybe we can accept that as a tradeoff for dependency simplicity.
---
