Gradle module metadata for 8.17.5 uses 8.10.0 of org.elasticsearch.client:elasticsearch-rest-client

[wilkinsona]

Java API client version

8.17.5

Java version

N/A

Elasticsearch Version

N/A

Problem description

https://repo1.maven.org/maven2/co/elastic/clients/elasticsearch-java/8.17.5/elasticsearch-java-8.17.5.module references org.elasticsearch.client:elasticsearch-rest-client:8.10.0. This is an old version. It also doesn't align with the pom file as https://repo1.maven.org/maven2/co/elastic/clients/elasticsearch-java/8.17.5/elasticsearch-java-8.17.5.pom references org.elasticsearch.client:elasticsearch-rest-client:8.17.5.

[sothawo]

I just had a look at 8.18.0, this has the same error

[l-trotta]

Hello, this is an unforeseen consequence of separating our release process from the Elastic-wide release pipeline, which would automatically synchronize the version of elasticsearch-rest-client with the version of the java client being built.
elasticsearch-rest-client rarely gets updates so version 8.10.0 should work exactly the same, but just to be sure you can force the version by adding the correct dependency - sorry for the inconvenience! We'll fix it in the following releases.

8.16.7 has a similar problem: being the first patch released independently from the server (version 8.16.7 of the server doesn't exist), it tries to pull the matching elasticsearch-rest-client version, which doesn't exist, so it also has to be forced to the latest available.

Having an independent release process will allow us to update the client when necessary (when we find bugs) without having to wait for weeks at times for the matching server release. Of course this will only be applied to patches, while we'll be in synch with server releases for major and minor versions.

[sothawo]

not directly related to the gradle problem here:

I just set the version for the rest-client in spring-data-elasticsearch to 8.10.0 and the elasticsearch-java-client to 8.17.5. My integration tests all pass, so this seems to be a possible solution(@wilkinsona would you fix it for Spring Boot and I leave it or would I need to fix the version for spring-data-elasticsearch as well?)

For upcoming versions, the next I would see for the big November release would be Elasticsearch 9, and as I saw in a first look, the rest-client isn't used there anymore at all.

[wilkinsona]

IMO, we shouldn't downgrade to 8.10.0 of elasticsearch-rest-client. A direct dependency on 8.17.5 may be an alternative solution as that should take precedence over the 8.10.0 version that would come transitively when building with Gradle. Perhaps this'll all be academic anyway if an 8.17.6 release happens that fixes the problem before our next round of releases in May.

[l-trotta]

Versions 8.17.6, 8.18.1 and 9.0.1 of the client will be available soon (early next week) with dependency issues sorted out. Since elasticsearch-rest-client barely gets updates, we'll just use the matching minor version for all subsequent releases of the client (so 8.17.6 will have version 8.17.0 of the rest-client, 8.18.1 will have 8.18.0 and so on).

The situation for version 9 of the client is a bit different: as we wrote in the official release notes, and in the new transport documentation, we've built a new implementation of the transport called Rest5Client, which is based on the Apache http client 5, while the legacy RestClient has been made optional: this is because it uses the Apache http client 4, which is now deprecated.

The legacy RestClient isn't deprecated yet, we plan to support it until the next major version of the client, so until then it still can be used by manually adding the elasticsearch-rest-client dependency to the project; otherwise the new Rest5Client is already available, more details in the docs.

@sothawo @wilkinsona Since this is a major update of the client we were thinking we could contribute to both spring-data-elasticsearch and spring-boot-autoconfigure to help with the implementation details of the new client, let us know if this is something you'd be interested in.

[l-trotta]

Closing this as it was solved in versions 8.18.1, 8.17.6 of the client, now available