Description
I'm raising this out of concern for the up and coming 2.0 release.
Currently, java clients communicating with an elasticsearch cluster use the following dependency.
<dependency>
<groupId>org.elasticsearch</groupId>
<artifactId>elasticsearch</artifactId>
<version>1.x.y or 2.x.y</version>
</dependency>This is a very large package, essentially containing all the code necessary to operate an elasticsearch node. What clients typically are interested in is the TransportClient code.
A major version bump is allowed to carry incompatible changes, and I will be encountering several scenarios where I will have to write java clients that communicate with both 1.x and 2.x clusters.
Traditionally you have been very good at maintaining backwards compatibility, I have 1.4 clients communicating with 1.7 clusters. So Minor versions have not been that much of an issue as long as you control the feature set you use for each cluster version.
The canonical way of solving this would be to extract the public API into a separate artifact, and under a different package name (e.g. org.elasticsearch2) to allow the two different client versions to co-exist both in maven, and in the classpath.
Considering the important comment on your java-api client documentation this seems to ramp up towards becoming a major hassle for me.
Will there be some way of combating this?