[GitHub] flink issue #5303: [hotfix][docs] Adjust RocksDb dependency docs

[StephanEwen <gi...@git.apache.org>]

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.


---