-
Notifications
You must be signed in to change notification settings - Fork 25.8k
Fix split package org.elasticsearch.client #81984
Copy link
Copy link
Closed
Labels
:Clients/Java Low Level REST ClientMinimal dependencies Java Client for ElasticsearchMinimal dependencies Java Client for Elasticsearch:Core/Infra/CoreCore issues without another labelCore issues without another label>bugTeam:Core/InfraMeta label for core/infra teamMeta label for core/infra teamTeam:Data Management (obsolete)DO NOT USE. This team no longer exists.DO NOT USE. This team no longer exists.modularizationJava Modules relatedJava Modules related
Metadata
Metadata
Assignees
Labels
:Clients/Java Low Level REST ClientMinimal dependencies Java Client for ElasticsearchMinimal dependencies Java Client for Elasticsearch:Core/Infra/CoreCore issues without another labelCore issues without another label>bugTeam:Core/InfraMeta label for core/infra teamMeta label for core/infra teamTeam:Data Management (obsolete)DO NOT USE. This team no longer exists.DO NOT USE. This team no longer exists.modularizationJava Modules relatedJava Modules related
Type
Fields
Give feedbackNo fields configured for issues without a type.
REST Clients - split package issue:
org.elasticsearch.clientorg.elasticsearch.clientco.elastic.clients.XXXorg.elasticsearch.client1 , 2 and 4 above contain, and have types in,
org.elasticsearch.client- leading to a split package.The HLRC is has been replaced by no.3 EJC. There is no planned 8.x artifact of the HLRC, and the only thing holding us back from deleting it from the codebase in master is the use in tests.
The LLRC is still active and will continue on. Ultimately the LLRC code base might move to the elastisearch-java repo.
LLRC does not have any dependency on server. And in fact is its own thing. Never loaded into the same classloader, etc. It's a separate distribution.
HLRC however depends on both server and LLRC. (the HLRC dependence on the server was a large motivation for the EJC)
Long story short, we can move things around as we like in 8.x since there won't be HLRC releases anymore with 8.0. But we much avoid doing so in 7.x as it may lead to breaking changes in applications using HLRC. With LLRC some consideration for the package name should be applied to help avoid/document breaking changes - ultimately, we should NOT change the package name.
If we need to, we can rename the package in server, from org.elasticserarch.client to something more appropriate and relevant to its purpose “internal client”.
see #78166