+1 for deprecating both the v2 and v5 (those using a transport client) components in 1.10, to be removed later. What do you think about refactoring the top-level ES bundle into 3 (v2, v5, REST) and creating profiles (deactivated by default) for the v2 and v5 bundles? I guess that could wait until actual "removal", and we can just tag the components @Deprecated or whatever for 1.10.
Also at that point if we had a public Extension Registry we could put those NARs up for folks to download. Note that the NARs are already published anyway (even if not included in the distro), [1] is an example of a NAR that is not included in the distro but is available for download. Just saying an ExtensionRegistry would make that easier :) Regards, Matt [1] https://repository.apache.org/content/repositories/releases/org/apache/nifi/nifi-hive3-nar/1.9.0/ On Wed, Feb 20, 2019 at 8:02 AM Mike Thomsen <[email protected]> wrote: > > I would like to mark the v5 Elastic bundle as deprecated in 1.10. Per > Elastic's official guidelines, the transport API--which it uses--is > deprecated in Elastic 7 and to be removed from at least public accessibility > in Elastic 8. > > https://www.elastic.co/guide/en/elasticsearch/client/java-api/master/transport-client.html > > So I'd like to nudge any users using it to be prepare to align themselves > more closely with Elastic's roadmap. > > ElasticSearch 5.X users can continue to use either the plain vanilla Elastic > bundle or start using the new REST API one going forward. The REST APIs don't > appear to be changing except in adding new features, so I think we can > deprecate and migrate users safely. > > (Also, it would free up about 30MB-33MB from our binary distro). > > Thoughts? > > Mikex
