Agreed. Another change we might want to consider is shading the dependencies of individual modules and the framework itself. This will make it easier to upgrade individual modules.
On Mon, Jan 29, 2018 at 2:58 PM, Mike Percy <mpe...@apache.org> wrote: > I think this change is important enough to warrant a breaking version bump. > Virtually every project depends on Guava, and Flume should certainly > shade/rename Guava for its internal use. > > I'd be on board with doing a Flume 2.0 to remove Guava from the public API. > > Mike > > On Mon, Jan 29, 2018 at 2:31 AM, Denes Arvay <de...@apache.org> wrote: > > > Hi Flume Community, > > > > It has come up a couple of times that we should fully remove (or at least > > shade) Guava from Flume, but unfortunately it's part of our public API > > [1,2,3]. > > As a first step I worked on FLUME-2957 [4] and created a pull request > [5]. > > Mike has already reviewed it, thanks for that. As he pointed out it is a > > breaking change thus it can be included in Flume 2.0 release only. > > > > Flume 2.0 will be a good opportunity to introduce other breaking changes > as > > well, so we might want to start collecting the features, improvements, > > other possible changes. > > > > What do you think? > > > > Best, > > Denes > > > > [1] > > https://github.com/apache/flume/blob/trunk/flume-ng- > > configuration/src/main/java/org/apache/flume/Context.java#L51 > > [2] > > https://github.com/apache/flume/blob/trunk/flume-ng- > > node/src/main/java/org/apache/flume/node/MaterializedConfiguration. > > java#L41 > > [3] > > https://github.com/apache/flume/blob/trunk/flume-ng- > > node/src/main/java/org/apache/flume/node/SimpleMaterializedConfiguratio > > n.java#L64 > > [4] https://issues.apache.org/jira/browse/FLUME-2957 > > [5] https://github.com/apache/flume/pull/195 > > >
