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 > >> > >> > >> > >
