Hi Helmut, Thank you for bringing this up on dev@ and thank you for the patch. I see there are other people people interested in this component upgrade as well.
As you are probably aware, a Flume committer will need to approve the change before I gets merged to trunk. My primary concern w/ merging this would be compatibility of the dependencies. Flume suffers from a kind of a "dependency hell" because of a lack of classloading support (either via OSGI or Java modules). See https://issues.apache.org/jira/browse/FLUME-2293 for a tracking ticket about that issue. What that means is that all of the components that Flume ships must have compatible dependencies with each other which makes changes like this more complex. Therefore I would like someone to verify that mvn dependency:tree does not show conflicts when run from the top level with the new patches. If memory serves, I believe Google Guava is likely to conflict. Also, I think that https://issues.apache.org/jira/browse/FLUME-3021 is a duplicate of https://issues.apache.org/jira/browse/FLUME-2921 which has additional information about the various issues that we need to solve to do this upgrade. I'd be happy to discuss this issue some more on this thread. Mike On Tue, Jan 23, 2018 at 12:57 AM, Wahrmann, Helmut <helmut.wahrm...@rsa.com> wrote: > Hi, > > Who decides if/when a patch or pull request gets merged to trunk? > Reason I am asking is for the Elasticsearch support. The current code in > trunk does not work with ES > 2.x. > Currently Elasticsearch is at 6.1. > > In FLUME-3021 we have several patches since March last year. > I have a patched Flume running at a customer since April last year without > any problems. > > So why not merging those changes into the trunk? > As I stated in my comment in FLUME-3021, it will not cause any problems, > cause the current trunk won't work with newer ES versions anyhow. > I doubt that someone is out there still running ES 0.95. > > best regards, > > Helmut >
