calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject [DISCUSS] Dropping old Guava support
Date Fri, 12 Oct 2018 19:41:46 GMT

Guava [11,24.1.1) is marked as being vulnerable via

Avatica currently depends on Guava 14.x and Calcite on 19.0. I'd like to 
start a discussion about how we ensure "safe" hygiene in our 
dependencies while still ensuring compatibility downstream.

I can see a couple of paths forward which are all related to 
relocating+bundling Guava in a non-standard location.

1. If we have Guava classes in the "user-facing API" for the projects, 
we should create a new module which relocates our version of Guava in a 
standard place for downstream projects to know about. This is required 
for developers to sanely use their IDEs (e.g. if we shade guava-$x, 
users cannot depend on guava-$x in their IDE as those classes don't 
actually exist). This is the "Maven way" to work around this problem.
2. If we only use Guava "internally", we can just shade Guava like normal.

I think we would require #1, but I haven't done any scan over the 
codebase recently. Given #1, we also should think about:

1a. Only Avatica has this special artifact for guava (or really, 
thirdparty dependencies)?
1b. Avatica and Calcite each have the special artifact for themselves.

If we can get away with 1a, great. Otherwise, 1b gives us lots of 
flexibility. I think this positions us in a place where we don't force 
downstream projects to move to a specific version of Guava (if they have 
analyzed their usage to know they are not vulnerable to some security 

- Josh

View raw message