The morphline solr sink has a dependency on Kite, which is a project abandoned 
by Cloudera. Someone would have to copy the relevant parts into the morphline 
repo and maintain them there. I have no interest myself in doing that.

I already split the Elasticsearch sink into the flume-search repo. As I recall 
I had problems building it. We have discussed that in other emails. It needs to 
be upgraded. I suspect the API we would have to use has an acceptable license 
but I believe ES itself has licensing problems. 

To be honest, I don’t know what the deal is with the legacy sources and why we 
even have them. We have an Avro source and Thrift source in Flume Core so I 
don’t know why we even keep them around.

I personally don’t use Hadoop or any of its related technology. While I know 
those are important, it is likely I personally will only apply PRs to any of 
them.

Ralph

> On Feb 26, 2023, at 10:29 AM, Bessenyei Balázs Donát <bes...@apache.org> 
> wrote:
> 
> +1.
> 
> For #3, which ones do you think can no longer be practically supported?
> 
> 
> Donat
> 
> On Sun, Feb 26, 2023 at 8:08 AM Ralph Goers <ralph.go...@dslextreme.com> 
> wrote:
>> 
>> As I mentioned last year I would like to start breaking up flume into 
>> separate repos. There are a few reasons for this:
>> 1. Flume has grown so large that the CI system can no longer build it. The 
>> jobs run out of disk space due to the large logs.
>> 2. The build takes a very long time to run.
>> 3. There are several components that can no longer be practically be 
>> supported.
>> 
>> To this end I am planning on creating the following Git repos:
>> flume-hadoop
>> flume-http
>> flume-irc
>> flume-jdbc
>> flume-jms
>> flume-kafka
>> flume-kudu
>> flume-legacy
>> flume-morphline
>> flume-scribe
>> flume-search
>> flume-spring-boot
>> flume-twitter
>> 
>> For the time being I would propose everything else remain in the current 
>> Flume repo.
>> 
>> Note that as each of these is populated they will each need to be released, 
>> However, most of these are fairly inactive so after the initial release they 
>> may not need to be touched very often.
>> 
>> Also, since Jira now requires new users to request us to create accounts for 
>> them I would propose that as each of these repos are set up that they be 
>> configured to enable GitHub Issues.
>> 
>> I am looking for feedback on this but if I don’t get any I plan to start 
>> work on this within a week or so.
>> 
>> Ralph

Reply via email to