Alternatively... I could just move these ones into solr-test-framework, where they will live a short life in 10.x until they can completely be removed. It solves a problem of how to exclude the Apache HttpClient JARs from the Solr server -- SOLR-17962 (I created just now; please look). It also doesn't disrupt some large WIP I have currently on the backburner to update the tests.
On Wed, Oct 15, 2025 at 8:09 PM David Eric Pugh <[email protected]> wrote: > I think now is the best time to deal with this! So many of the > deprecations etc are all around this space, and it's super confusing. > On Wednesday, October 15, 2025 at 04:21:52 PM EDT, David Smiley < > [email protected]> wrote: > > I propose that I execute at least part of this plan Thursday night for > main > branch, backport to 10 straight away: > * remove BaseHttpSolrClient, the deprecated base class of HttpSolrClient > * rename HttpSolrClient to HttpApacheSolrClient > * rename CloudLegacySolrClient to CloudApacheSolrClient > * rename LBHttpSolrClient to LbApacheSolrClient (lowercase 'b') > * rename ConcurrentUpdateSolrClient to ConcurrentUpdateApacheSolrClient > * rename HttpClusterStateProvider to HttpApacheClusterStateProvider > > I will do that purely mechanically by IntelliJ IDEA. The PR will be no fun > to look at and will have no other changes whatsoever to review. Ref guide, > CHANGES.txt, can be in another PR (commit) so that it's not lost in a sea > of wrote changes. > > The above only changes deprecated clients. "HttpSolrClient" (a great-name) > won't exist but let's add afterwards/soon. The rest of the renames can be > in a follow-up, that I'll announce on this thread. I could do likewise for > the other clients. I'm aware of work James is doing so I don't want to > disturb that at the moment. > > If I get a couple +1 and no dissent, I'll proceed. > > On Mon, Sep 29, 2025 at 1:40 PM James Dyer <[email protected]> wrote: > > > I agree with all the "HTTP" renames proposed here. I do want to point > > out that with the Load Balanced client, we opted to make > > `LBHttp2SolrClient` work with both the Jetty and JDK client variants. > > (see https://github.com/apache/solr/pull/2828) My hope is that the > > same can be done for both `CloudSolrClient` and > > `ClusterStateProvider`. For these more-advanced clients that really > > just layer on more functionality, we should try not have a bespoke > > variant for each underlying base client implementation. With that in > > mind, the less-specific the naming the better. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
