Re: [DISCUS] Flink SQL Client dependency management

Hi everyone, thanks for your opinions. So the majority voted for option (2) fat jars that are ready to be used. I will create an Jira issue and prepare the infrastructure for the first connector and first format. Regards, Timo Am 3/1/18 um 11:38 AM schrieb Fabian Hueske: I agree, option

Re: [DISCUS] Flink SQL Client dependency management

I agree, option (2) would be the easiest approach for the users. 2018-03-01 0:00 GMT+01:00 Rong Rong : > Hi Timo, > > Thanks for the initiating the SQL client effort. I agree with Xingcan's > points, adding to it (1) most of the user for SQL client would very likely > to

Re: [DISCUS] Flink SQL Client dependency management

Hi Timo, Thanks for the initiating the SQL client effort. I agree with Xingcan's points, adding to it (1) most of the user for SQL client would very likely to have little Maven / build tool knowledge and (2) most likely the build script would grow much complex in the future that makes it

Re: [DISCUS] Flink SQL Client dependency management

I think one problem with the "one fat jar for all" is that some dependencies clash in the classnames across versions: - Kafka 0.9, 0.10, 0.11, 1.0 - Elasticsearch 2, 4, and 5 There are probably others as well... On Tue, Feb 27, 2018 at 2:57 PM, Timo Walther wrote: > Hi

Re: [DISCUS] Flink SQL Client dependency management

Hi Xingcan, thank you for your feedback. Regarding (3) we also thought about that but this approach would not scale very well. Given that we might have fat jars for multiple versions (Kafka 0.8, Kafka 0.6 etc.) such an all-in-one solution JAR file might easily go beyond 1 or 2 GB. I don't

Re: [DISCUS] Flink SQL Client dependency management

Hi Timo, thanks for your efforts. Personally, I think the second option would be better and here are my feelings. (1) The SQL client is designed to offer a convenient way for users to manipulate data with Flink. Obviously, the second option would be more easy-to-use. (2) The script will

Re: [DISCUS] Flink SQL Client dependency management

My first intuition would be to go for approach #2 for the following reasons - I expect that in the long run, the scripts will not be that simple to maintain. We saw that with all shell scripts thus far: they start simple, and then grow with many special cases for this and that setup. - Not

[DISCUS] Flink SQL Client dependency management

Hi everyone, as you may know a first minimum version of FLIP-24 [1] for the upcoming Flink SQL Client has been merged to the master. We also merged possibilities to discover and configure table sources without a single line of code using string-based properties [2] and Java service provider