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 connectors. Thanks, Thomas [1] https://lists.apache.org/thread.html/3de9d2353cf22aea0448fb744314103b5f88195216acc3bff449354a@%3Cdev.flink.apache.org%3E On Wed, Mar 6, 2019 at 7:13 AM Thomas Weise <t...@apache.org> wrote: > 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 <aljos...@apache.org> > wrote: > >> I think the two links are identical. >> >> > On 6. Mar 2019, at 16:05, Thomas Weise <t...@apache.org> 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 applications and the (shaded) Guava isn't user facing. >> > >> > [1] >> > >> https://lists.apache.org/thread.html/3599d95020604e2476bd794c55a11bc1c3a958a83a3c9c45c50630c1@%3Cdev.flink.apache.org%3E >> > [2] >> > >> https://lists.apache.org/thread.html/3599d95020604e2476bd794c55a11bc1c3a958a83a3c9c45c50630c1@%3Cdev.flink.apache.org%3E >> > >> > >> > On Wed, Mar 6, 2019 at 6:41 AM Chesnay Schepler <ches...@apache.org> >> wrote: >> > >> >> 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 for that >> matter) >> >> to far just creates headaches when bumping the dependency. >> >> >> >> One core principle that we *must* follow is that shaded dependencies >> are >> >> neither exposed to user-code nor contained in the user-jar. Otherwise >> we >> >> end up again in a situation where we cannot increment dependencies >> >> without breaking compatibility for users. >> >> >> >> The PR at hand has a few issues in this regard. The guava limiter is >> >> only used in tests but is not a test class, yet isn't annotated with >> >> either Public(Evolving)/Internal. As it stands I cannot judge whether >> >> this is truly supposed to be an example / test utility or actually a >> >> user-facing class. >> >> If this is to be used by connectors, which are included in the >> user-jar, >> >> then we're violating the principle above, in which case the class >> should >> >> be relocated/removed. >> >> >> >> On 06.03.2019 15:10, Aljoscha Krettek wrote: >> >>> 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 to core packages that we might never have really >> discussed. >> >> I think we should do that now. >> >>> >> >>> Quite some time ago an effort was started to reduce our dependency on >> >> Guava [2] because of some problems with version stability and >> dependency >> >> conflicts. At some later point, we created shaded guava so that we >> could >> >> use it without clashes [3]. I believe we now have shaded Guava only in >> >> runtime modules where it wasn’t easy to remove and CEP. >> >>> >> >>> With the creation of shaded guava, I think we are in a bit of a limbo >> >> situation where it is not exactly clear what our stance towards it is, >> >> because it is easy to add to modules, as evident by the aforementioned >> PR. >> >> I think we should discuss that situation and agree upon a common >> stance on >> >> the topic. >> >>> >> >>> In general, I think the surface (which includes classes, interfaces, >> and >> >> dependencies, among other things) of core modules should be kept as >> lean as >> >> possible. (all modules really) >> >>> >> >>> What do you think? >> >>> >> >>> Best, >> >>> Aljoscha >> >>> >> >>> [1] https://github.com/apache/flink/pull/7679 < >> >> https://github.com/apache/flink/pull/7679> >> >>> [2] https://issues.apache.org/jira/browse/FLINK-3700 < >> >> https://issues.apache.org/jira/browse/FLINK-3700> >> >>> [3] https://issues.apache.org/jira/browse/FLINK-6982 >> >> >> >> >> >> >> >>
