Although the more I think about it I guess this issue is going to be present no matter what until we can go full HTTP. Just to throw it out there, why not drop node/transport and go full HTTP? It's the future anyway, we can do it right now to support 2.x and 5.x and do it even cleaner once Jest PRs are merged. Then we have a single JanusGraph distribution that supports ES 1.x-5.x. User's only have to update their configs to change 9300 to 9200.

On Thursday, March 2, 2017 at 9:40:07 AM UTC-6, Keith Lohnes wrote:

I started some conversation over at https://github.com/JanusGraph/janusgraph/pull/79#pullrequestreview-24343839, and Jason Plurad suggested I move that over here. 

I have some code that's been used in a Titan deployment using the apache licensed Jest ES http client. There was some discussion in that PR about whether to continue to support the Transport/node client in there as well.

The key points of the conversation there

1. Versions to support (1.x, 2.x, 5.x)

   With the Jest client, we could support all three pretty easily. 1 vs 2.x and 5.x would be changing the .jar out.  There's some open PRs in the Jest repo that need to get merged for 5.x support, but once those are and we update the jar version, we'd be able to support 5.x. Maintaining 1.x support for a little while would be nice for people with production Titan instances, as Adam Phelps pointed out. 1.x and 2.x could use the same code, they just need different jars.

2. HTTP vs Transport/Node

    I think in #92 there's a mention of Transport being deprecated. My first instinct is to say that Janus should mark Transport/Node as deprecated and continue to support Transport/Node clients until a major version release at which point support could be removed.  I have some work done to split out the Transport/Node clients from the Http client, and make for an easy removal once that decision has been made.