Thanks for your feedback!
Since FLINK-15090 got resolved, the next step I'd like to decouple dep from
flink-streaming to flink-java. They should not have any dependency
conceptually but happen we have some common formats in flink-java module.
Best,
tison.
Till Rohrmann 于2020年3月17日周二 下午10:33写道：
I'm a bit late to the party but also +1 from my side. Pulling the
dependency graph straight is very good idea and will improve the
maintainability in the long run.
Cheers,
Till
On Tue, Mar 10, 2020 at 5:21 AM tison wrote:
> Thanks for your attention!
>
> Best,
> tison.
>
>
> Aljoscha Krettek 于
Thanks for your attention!
Best,
tison.
Aljoscha Krettek 于2020年3月9日周一 下午10:08写道：
> On 09.03.20 03:15, tison wrote:
>
> > So far, there is a PR[1] that implements the proposal in this thread.
> >
> > I look forward to your reviews or start a vote if required.
>
> Nice, I'll try and get to revie
On 09.03.20 03:15, tison wrote:
So far, there is a PR[1] that implements the proposal in this thread.
I look forward to your reviews or start a vote if required.
Nice, I'll try and get to review that this week.
Best,
Aljoscha
Hi guys,
So far, there is a PR[1] that implements the proposal in this thread.
I look forward to your reviews or start a vote if required.
Best,
tison.
[1] https://github.com/apache/flink/pull/10526
tison 于2020年3月6日周五 下午4:11写道：
> Hi,
>
> Thanks for your rapid replies!
>
> Correctly when the
Hi,
Thanks for your rapid replies!
Correctly when the dependencies to flink-client & flink-runtime broken
we can make flink-streaming-java scala-free. And even part of the goal,
i.e., that to flink-client reversed we can directly compile streaming
pipeline in flink-client instead of relying on re
Hi,
+1 to make flink-streaming-java an API only module and solve it sooner
rather than later.
It would be more clear to only expose an SDK module for writing jobs.
Another benefit I can see is: the flink-streaming-java would be scala-free
if we reverse the dependencies and this would be really ni
Big +1 also from my side.
This will eliminate some work-arounds used so far to bypass the module
structure (like code using reflection to extract a JobGraph from a
Pipeline).
I agree with Stephan that with proper documentation, release notes and
tooling update, it will hopefully not be a big hass
+1 to this fix, in general.
If the main issue is that users have to now add "flink-clients" explicitly,
then I think this is okay, if we spell it out prominently in the release
notes, and make sure quickstarts / etc are updated, and have a good error
message when client/runtime classes are not fou
Hi,
thanks for starting the discussion, Tison!
I'd like to fix this dependency mess rather sooner than later, but we do
have to consider the fact that we are breaking the dependency setup of
users. If they they only had a dependency on flink-streaming-java before
but used classes from flink-c
Hi devs,
Here is a proposal to reverse the dependency from flink-streaming-java to
flink-client, for a proper
module dependency graph. Since it changes current structure, it should be
discussed publicly.
The original idea comes from that flink-streaming-java acts as an API only
module just as wha
11 matches
Mail list logo
