Pinging @elastic/clients-team (Team:Clients)

Pinging @elastic/es-ql (Team:QL)

@astefan I reached out to @mark-vieira to ask about adding a new-java-client dependency in our tests for that purpose, and he's hesitant for us to do it. @mark-vieira can you elaborate on your reasoning?

Right now this isn't simple becuase the new Java client lives in its own repository and therefore we would have to rely on snapshot releases for using it in the Elasticsearch build. Right now the Java client is only published as part of the unified release process, meaning that after version bumps, it can take days to get a new artifact. This would mean any builds relying on that artifact would fail in the meantime.

We'll want the new Java client to move to the new daily releasable artifacts process (like ML) before we introduce any dependency on it.

From the practical point of view, the PR LGTM.
👍 about using the low level REST API for tests (thank you @mark-vieira, the explanation makes definitely sense).

Just out of curiosity: if I got it right, the code of the new API is automatically generated.

elastic/elasticsearch-java@d7451d0

Is there anything we have to know or to take into consideration from the QL side about that? Maybe it has impacts on how we can extend (E)QL capabilities?

We'll want the new Java client to move to the new daily releasable artifacts process (like ML) before we introduce any dependency on it.

@mark-vieira @joegallo is there an issue I can track about this future move to daily releaseable artifacts? Thanks

@mark-vieira @joegallo is there an issue I can track about this future move to daily releaseable artifacts? Thanks

Not that I'm aware of. I think the platform release team will coordinate this with the clients team.

We'll want the new Java client to move to the new daily releasable artifacts process (like ML) before we introduce any dependency on it.

@mark-vieira what are "daily releasable artifacts"? Is this different from daily snapshots, which are already produced for the new Java client?

One thing to keep in mind is that the new Java client is code-generated from the API specification. So an API change on the server means updating the API spec and generating the client code. Updating the generated code is currently a manual process, although it could (and should!) be automated.