flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From StephanEwen <...@git.apache.org>
Subject [GitHub] flink issue #5303: [hotfix][docs] Adjust RocksDb dependency docs
Date Tue, 16 Jan 2018 15:39:30 GMT
Github user StephanEwen commented on the issue:

    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
      - 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.


View raw message