Eric and Jan agreed/+1 in Slack to moving these to solr-test-framework. I was asked what the biggest risk in doing such is. The only thing I can think of, which I dunno is a "risk", but it's what to do about the existence of the desirable class name "HttpSolrClient". If we move it to solr-test-framework, the name is still reserved, and thus preventing creating such a base class. It'd be nasty to have the same name exist in two packages, even if one is deprecated. At the point we want to use that name, which will be very very soon if we seek 10.0, I could rename HttpSolrClient to HttpApacheSolrClient (without changing usages; thus breaking compile) as previously agreed, and then introduce a base HttpSolrClient in a separate commit, as the foundation of all such HTTP SolrClients (3). Then fix compilations by referencing HttpApacheSolrClient where it's truly needed, intentionally limiting to as few lines as possible. Such lines (all in tests) will need to eventually migrate anyway, remember.
On Wed, Oct 15, 2025 at 8:50 PM David Smiley <[email protected]> wrote: > 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] >> > >> > >> > >
