Re: Re[2]: Google Guava in Ignite 3

The voting has been started here On Mon, Sep 6, 2021 at 8:11 PM Andrey Gura wrote: > Alexander, > > Feel free to start voting. Please, refer to this discussion in order

Re: Re[2]: Google Guava in Ignite 3

Alexander, Feel free to start voting. Please, refer to this discussion in order to avoid a new flaming thread in the voting topic. On Thu, Sep 2, 2021 at 6:04 PM Alexander Polovtcev wrote: > > Andrey, > > > It just doesn't work. If there is precedent of usage of Guava methods > then somebody

Re: Re[2]: Google Guava in Ignite 3

Andrey, > It just doesn't work. If there is precedent of usage of Guava methods then somebody will use other methods. Maybe you are right. I would suggest a vote on whether we should allow Guava methods in the codebase or not. Let's do that in a separate thread? In the meantime we will prohibit

Re: Re[2]: Google Guava in Ignite 3

> So I would propose to allow at least *some* methods that we consider useful, > while disallowing everything else. It just doesn't work. If there is precedent of usage of Guava methods then somebody will use other methods. > I think that the benefits of using Guava methods instead of

Re: Re[2]: Google Guava in Ignite 3

Andrey, I think that the benefits of using Guava methods instead of copy-pasting them are quite obvious: you don't have to copy-paste code and support it. I also find this situation quite strange: we have a dependency and copy-paste code from it instead of using it directly. On Thu, Sep 2, 2021

Re: Re[2]: Google Guava in Ignite 3

Alex, As I understand we agree to shade Guava transitive dependency and you said a 'maven-shade-plugin' can drop unused Guava methods to reduce the footprint of Ignite jar. At this point, there is no difference between copy-pasting Guava method to Ignite and use Guava one. The resulted jar will

Re: Re[2]: Google Guava in Ignite 3

Hi, Andrey! I mostly agree with your proposal, but, since we already have some copy-paste in our code, can we at least use Guava to remove it? So I would propose to allow at least *some* methods that we consider useful, while disallowing everything else. I understand that it may be difficult to

Re: Re[2]: Google Guava in Ignite 3

Follow up On Mon, Aug 23, 2021 at 1:22 PM Andrey Gura wrote: > > Igniters, > > What I actually didn't understand from this thread: Is Guava allowed > in production code of Ignite 3 modules (not dependencies like > Calcite)? > > While we agree with using shading I don't see any arguments about >

Re: Re[2]: Google Guava in Ignite 3

Igniters, What I actually didn't understand from this thread: Is Guava allowed in production code of Ignite 3 modules (not dependencies like Calcite)? While we agree with using shading I don't see any arguments about using Guava library in our code base except for the fact that we have some

Re: Re[2]: Google Guava in Ignite 3

Guys, Thanks again for your responses. I've created a ticket about using the Shade plugin in order to understand if it is possible to shade and minimize Guava, I will start working on it shortly: https://issues.apache.org/jira/browse/IGNITE-15354 On Tue, Aug 10, 2021 at 1:51 PM Courtney Robinson

Re: Re[2]: Google Guava in Ignite 3

I think since Calcite brings it in already then your arguments make sense. Would it be pinned to the same version as Calcite? Risk NoSuchMethodError at runtime if not. +1 On Mon, Aug 9, 2021 at 9:56 AM Alexander Polovtcev wrote: > Zhenya, Courtney, Andrey, > > What do you think about my

Re: Re[2]: Google Guava in Ignite 3

Zhenya, Courtney, Andrey, What do you think about my arguments, was I able to convince you? I would like to reach some consensus here. At the moment, my original points still stand, I'm also ok with shading Guava if needed, though I think it is not necessary at this point. On Fri, Aug 6, 2021 at

Re: Re[2]: Google Guava in Ignite 3

Zhenya, > But there is no restrictions from running ignite server nodes from some other code with it`s own guava version seems we obtain fast path to jar hell here? I'm not sure if I fully understand your question, but it looks like we are in this situation already, because we have some

Re[2]: Google Guava in Ignite 3

Alexander, first of all looks like Ivan Daschinsky approach about thin client use only and shadow plugin are cover all Andrey Mashenkov listing problems. But there is no restrictions from running ignite server nodes from some other code with it`s own guava version seems we obtain fast path to

Re[2]: Google Guava in Ignite 3

Andrey, seems we can use [1] it help us with point 1 in your comment, isn`t it ?   [1]  https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html   >-1 >It is sad to say -1, as Guava has very useful stuff and it looks easier to >add it as a dependency