Hi Mike,

I gave it a try and changed the Solr version to 7.2.1. It all compiled well.
Only the tests were failing, because SolrServer, which is needed in the test 
cases to connect to the embedded Test Server is no longer available in 
org.apache.solr.client.solrj.
But that's not needed in the "production" version.
I cannot test however if it really works, since I don't have access to a  Solr 
installation.

I understand your discussion with the dependency problem, but I need to move 
ahead.
It doesn't help me to have a Flume 1.9 or 2.0 released with no dependency 
problems, but it doesn't support the latest Elasticsearch client, which are 
needed by my customer.

And by the time, you will release Flume 1.9, the ES project is at version 8, 
where they will drop support for the Transport client.
So I am in the urgent need to develop support for the new ElasticSearch Rest 
Client.
For that I need the changes which are done in Flume-3021.

So I continue my work in a fork and will publish Pull requests . Once the 
dependencies problems are sorted out, you're welcome to include my changes in 
your trunk. 

best regards,

Helmut
 

-----Original Message-----
From: Mike Percy [mailto:mpe...@apache.org] 
Sent: Dienstag, 30. Jänner 2018 04:57
To: dev@flume.apache.org
Subject: Re: Merging to trunk?

On Mon, Jan 29, 2018 at 10:48 AM, Wahrmann, Helmut <helmut.wahrm...@rsa.com
> wrote:
>
> I think it is not a problem to distribute the modules together if we 
> have maintainers for them.
> It doesn't make sense to release Flume 1.9 in 2018 with support for 
> module versions which were current in 2013.


> Best way would be to identify people willing to upgrade the modules to 
> their latest version.
> If we can't find someone, we should distribute it separately.


I would be OK with upgrading Solr and ES simultaneously if we can do it in a 
compatible way. However, there is no guarantee that the latest versions of Solr 
and ES will be dependency-compatible. If they are, I would certainly be in 
favor of merging such a patch.

On Mon, Jan 29, 2018 at 2:49 AM, Ferenc Szabo <szabofe...@apache.org> wrote:

> I believe, that a clean and maintainable solution would be if the 
> engine/framework itself could be separated from everything else, the 
> dependency directions would be fixed, plugins would depend only on 
> api-s  and after that, any source/sink/etc implementation would come 
> as an individual module/plugin and would be loaded with an isolated 
> classloader.
>

I agree that isolating Flume plugins from each other would solve this problem 
once and for all. I wonder if we can do both things: come up with a short-term 
"band-aid" patch to allow us to upgrade ES / Solr and also come up with a 
longer-term plan to solve the underlying problem.

Mike

Reply via email to