Hi,
Thanks for the follow-up.
@Aljoscha Krettek if there is consensus, can we also
backport FLINK-11501 for 1.8.1? (The Guava dependency was the reason we
didn't.)
Thanks,
Thomas
On Mon, Mar 25, 2019 at 8:07 AM Stephan Ewen wrote:
> I would be fine with that as well.
>
> Let's keep the
I would be fine with that as well.
Let's keep the attitude to maintain a slim dependency footprint, but Guava
could be part of that small footprint.
As long as we ensure it is our vendored (pre-shaded) version and all
modules use the same version (managed version in the root pom).
Best,
Stephan
Hi,
By now, I think it’s fine to have Guava (our shaded guava) as a dependency in
flink-core. It’s a very useful library and I don’t see problems with version
clashes because it’s relocated to our namespace.
If no-one objects, I would just leave the dependency in as-is and conclude this
I want to bring this back to attention - with the concern raised here we
are still looking for a potentially better answer to the original issue [1].
We have a class that depends on Guava (in its implementation, not the
public interface) and we want to make it available for use with multiple
How I managed to do that..
Here is the discussion about the shared package:
https://lists.apache.org/thread.html/3de9d2353cf22aea0448fb744314103b5f88195216acc3bff449354a@%3Cdev.flink.apache.org%3E
On Wed, Mar 6, 2019 at 7:10 AM Aljoscha Krettek wrote:
> I think the two links are identical.
>
I think the two links are identical.
> On 6. Mar 2019, at 16:05, Thomas Weise wrote:
>
> For more context, see [1] [2]
>
> The GuavaFlinkConnectorRateLimiter is an implementation of the rate limiter
> interface that uses Guava. It is not a test class, it is intended to be
> used in
For more context, see [1] [2]
The GuavaFlinkConnectorRateLimiter is an implementation of the rate limiter
interface that uses Guava. It is not a test class, it is intended to be
used in applications and the (shaded) Guava isn't user facing.
[1]
Hi,
yes I also fully agree that it is time to write down all these implicit
convensions that we've learned throught the last years. The Flink
community is growing quite rapidly right now and we must ensure that the
same mistakes do not repeat again.
Keeping the number of dependencies low is
I fully agree that we should write down this kind of conventions that
committers have setup implicitly.
I agree that we should keep flink-core as lean as possible.
On guava usages in general my current stance is that we should only use
guava if necessary. Spreading it (or other dependencies
Hi,
I recently saw that we added a dependency on our shaded-guava to flink-core
[1]. Just for the record, I don’t want do diminish the contributions of anyone
involved in the PR in any way. It just made me realise that we have some
implicit agreements or assumptions about adding certain things
10 matches
Mail list logo
