Hi Rui,
I suppose we could do some benchmarking on what works well for the resource
providers that Flink relies on e.g. Kubernetes. Based on conferences and
blogs, it seems most people are relying on Kubernetes to deploy Flink and
the restart strategy has a large dependency on how well Kubernetes
Hi Trystan,
I imagine you can create 2 jars, one should only have a class with the main
method, and the other should be a fat jar with everything else for your
job. If you create a custom image where your fat jar is placed under
/opt/flink/lib/ then I think it would "just work" when specifying the
Rui,
I don't have any direct experience with this topic, but given the
motivation you shared, the proposal makes sense to me. Given that the new
default feels more complex than the current behavior, if we decide to do
this I think it will be important to include the rationale you've shared in
the
Same behaviour and assumption on my side Alexey. Thanks for testing it.
Günter
On 17.11.23 09:40, Alexey Novakov via user wrote:
I would expect *flink-connector-kafka:3.0.1-1.18* pointing to
*org.apache.flink:flink-connector-base:1.18.0* not to *1.17.0*
However, SBT compiles my project ok usin
I would expect *flink-connector-kafka:3.0.1-1.18* pointing to
*org.apache.flink:flink-connector-base:1.18.0* not to *1.17.0*
However, SBT compiles my project ok using such versioning:
val flinkVersion = "1.18.0"
val flinkVersion17 = "1.17.1"
val flinkDependencies = Seq(
"org.flinkextended" %% "f
