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