Thank you for the reply, Courtney! > We use Ignite entirely as a thick client and already have Guava version conflicts from other projects
AFAIK and as Ivan wrote before, there are no plans of providing the thick client functionality in Ignite 3, so this may not be an issue. > Even Calcite itself already has Guava conflicts because of the Cassandra adapter. I'd +1 this but really only if it will be shaded. Will shading solve this issue? Do I understand correctly, that you propose to use the Shade plugin and, apart from constructing a fat jar, also to rewrite package names? If yes, will this work for transitive dependencies? > Also, what impact will this have on peer class loading? Something I think shading also resolves I don't know anything about peer class loading in terms of Ignite 3, but this may be a valid point. It would be nice if someone could comment on this. Overall, I'm ok with shading Guava if needed, it does not contradict any of my original arguments. On Thu, Aug 5, 2021 at 9:05 PM Courtney Robinson <courtney.robin...@hypi.io> wrote: > Can I suggest shading Guava? > Guava and Netty are two notorious libraries for version conflicts because > of their popularity and usefulness. > Other projects (ES for example solved it by shading them it > https://github.com/elastic/elasticsearch/issues/2091#issuecomment-7156766 > ). > > We use Ignite entirely as a thick client and already have Guava version > conflicts from other projects (Calcite being one because we use it directly > already) so Ignite bringing its own will only make this worse when we get > to V3. > > Even Calcite itself already has Guava conflicts because of the Cassandra > adapter. I'd +1 this but really only if it will be shaded. > > Regards, > Courtney Robinson > Founder and CEO, Hypi > Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io> > > <https://hypi.io> > https://hypi.io > > > On Thu, Aug 5, 2021 at 5:56 PM Zhenya Stanilovsky > <arzamas...@mail.ru.invalid> wrote: > > > > > alexpolovtcev please clarify what do you mean under : «possibility of > > using Guava in Ignite 3», using how necessary dependency of calcite or > > using like «using in our code» ? If using in code, i -1 here. > > thanks. > > > > > > >Hello, dear Igniters! > > > > > >I would like to discuss the possibility of using Guava > > >< https://github.com/google/guava > in Ignite 3. I know about the > > restrictive > > >policy of using it in Ignite 2, but I have the following reasons: > > > > > >1. We are de-facto using it already as an implicit dependency, since the > > >Calcite module depends on it, and Calcite is going to stay for a while > =) > > >2. AFAIK, the "bytecode" module is copied into the codebase only to > strip > > >Guava away from it. We can remove this module, which will improve the > > >maintainability of the project. > > >3. We have some copy-paste of Guava code in the project. For example, > see > > >this > > >< > > > https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L136 > > > > > >and this > > >< > > > https://github.com/apache/ignite-3/blob/main/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L428 > > > > > >. > > >4. Regarding security concerns, this report > > >< > > > https://www.cvedetails.com/product/52274/Google-Guava.html?vendor_id=1224 > > > > > >shows no major vulnerability issues for the last three years. > > > > > >Taking these points into account, I propose to allow using Guava both in > > >production and test code and to add it as an explicit dependency. > > > > > >What do you think? > > > > > >-- > > >With regards, > > >Aleksandr Polovtcev > > > > > > > > > -- With regards, Aleksandr Polovtcev
