Hi all, I somewhat agree with Helmut. I think we should detach every component from the framework and provide an isolated classloader for them to avoid the dependency issues we have now.
Basically, flume itself should be just the framework and every source/sink/channel/interceptor/etc would come as a plugin. We would have "official" plugins in the flume repository but as separate maven projects. After the 1.9 release, we could start planning it for 2.0 as it would be easiest (or only possible) to do with breaking changes, however, it would be good to aim for compatibility with 1.x plugins. What do you think about that? Additionally, I would be happy to maintain a plugin list for flume with the 3rd party/community plugins. Regards, Ferenc On Mon, Nov 19, 2018 at 1:19 PM Wahrmann, Helmut <helmut.wahrm...@rsa.com> wrote: > Hi all, > > What are we doing with integrations having no maintainer? > > An example is the morphline sink. It supports Solr 4.3 and Apache has > already relased Solr 7.5.0. > Kite SDK is at 1.1. > Seems that no one is taking care of it. > > On the other site we are still "supporting" Elasticsearch 0.90.1, while > ElasticSearch is already on 6.5. > Having a dependency of Lucene between Solr and Elastic I cannot push my > changes to flume. > > So while there would be a maintainer for ElasticSearch, new features > cannot be introduced, because of the above. > > Shouldn't we deprecate old stuff, where no maintainer is active? > If 1.9 is released with support of outdated SOLR and ElasticSearch, no one > would use Flume anyhow. > I doubt that someone would downgrade the ElasticSearch cluster to 0.90 > just to be able to pump in events via Flume. > > I keep a working ElasticSearch 6.x Fork anyhow, but would like to > contribute back to the project. > > Note: I have tried to upgrade SOLR support to the newest version, but it > fails on the test cases and I don't have anything to test. > > > Thanks, > > Helmut > >
