That makes sense. It might be interesting at our next community meet up to bring up some of these “umbrella” tickets and socialize them around, to activate some folks!
> On Apr 30, 2024, at 9:21 AM, Jan Høydahl <jan....@cominvent.com> wrote: > > There is an umbrella issue for major SolrJ changes > https://issues.apache.org/jira/browse/SOLR-15730. Some of the sub tasks are > 10.0 only. Could add a rename jira there? > > Jan > >> 30. apr. 2024 kl. 15:04 skrev Eric Pugh <ep...@opensourceconnections.com >> <mailto:ep...@opensourceconnections.com>>: >> >> Please! It would be nice if someone laid out the work to be done in some >> tickets so folks could pick it up…. Otherwise it looks a bit daunting! >> >>> On Apr 30, 2024, at 7:38 AM, Jan Høydahl <jan....@cominvent.com> wrote: >>> >>> In Solr 10, SolrJ will have new maven coordinates and the need to >>> explicitly pull in solrj-xx dependencies. So we coult also do a few key >>> renames such as "Http2SolrClient" -> "HttpJettySolrClient", while we're >>> busy breaking things :) >>> >>> Jan >>> >>>> 30. apr. 2024 kl. 13:21 skrev Jason Gerlowski <gerlowsk...@gmail.com>: >>>> >>>> Thanks for summarizing this all David! >>>> >>>> We have HttpSolrClientBase AND BaseHttpSolrClient?! >>>> >>>> A bit of the messiness here seems like it will resolve itself >>>> "automatically" if we make good on removing the existing deprecations. >>>> (Though given how "entrenched" the Apache client is, that will require >>>> a good bit of work...). >>>> >>>> I like the convention established by the JDK client, of naming our >>>> low-level SolrClient implementations based on the HttpClient vendor in >>>> use. IMO doing otherwise can be confusing in a few different ways. >>>> It's not high on my list to act on it immediately, but if there's >>>> enough consensus on the idea of renaming (e.g.) Http2SolrClient, I >>>> could file a ticket to document that as an ideal step and maybe it'll >>>> hook someone eventually? >>>> >>>> Best, >>>> >>>> Jason >>>> >>>> On Thu, Apr 25, 2024 at 11:34 PM Mark Miller <markrmil...@gmail.com> wrote: >>>>> >>>>> It's too bad HttpSolrServer setup this client philosophy. It's momentum >>>>> was directly opposite to what you want: a SolrClient that can optionally >>>>> stream or load balance and a SolrCloudClient that wraps it. >>>>> >>>>> [Mark Miller - Chat @ >>>>> Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=2kigx5) >>>>> [2kigx5] >>>>> >>>>> On April 25, 2024 at 20:07 GMT, David Smiley <dsmi...@apache.org> wrote: >>>>> >>>>> Our SolrJ class hierarchy is looking rather confusing right now for >>>>> the HTTP ones especially. This message is mostly a big FYI, with some >>>>> reflections and a recommendation or two. >>>>> >>>>> SolrClient >>>>> - BaseHttpSolrClient (NOT yet deprecated but should be?) >>>>> - - HttpSolrClient (based on Apache HttpClient; deprecated) >>>>> - - - DelegationTokenHttpSolrClient >>>>> - CloudSolrClient >>>>> - - CloudHttp2SolrClient >>>>> - - CloudLegacySolrClient (based on Apache HttpClient; deprecated) >>>>> - ConcurrentUpdateHttp2SolrClient >>>>> - - ... >>>>> - ConcurrentUpdateSolrClient (based on Apache HttpClient; deprecated) >>>>> - - ... >>>>> - HttpSolrClientBase (this is new) >>>>> - - Http2SolrClient >>>>> - - HttpJdkSolrClient (this is new; based on the JDK HttpClient) >>>>> - LBSolrClient >>>>> - - LBHttp2SolrClient >>>>> - - LBHttpSolrClient (based on Apache HttpClient; deprecated) >>>>> >>>>> In retrospect, we can see that some past names weren't so great after >>>>> all. I think our clients should reflect the vendor/source of the >>>>> HttpClient. "HttpJdkSolrClient" is the newest client, and it reflects >>>>> the vendor (JDK provided HttpClient). Personally I don't care enough >>>>> to rename all the ones with "2" in there to have "Jetty" but that's >>>>> what they are -- if it has a "2", it's using Jetty (and it supports >>>>> 1.1; FYI JDK also supports both 1.1 and 2 as well). The clients for >>>>> Apache HttpClient are all deprecated so perhaps we continue to leave >>>>> them be, mostly. Removing them will take some time; they are >>>>> entrenched! BaseHttpSolrClient (the parent of HttpSolrClient) is at >>>>> the moment even more confusing because HttpSolrClientBase was just >>>>> added. BaseHttpSolrClient should be removed now; it only holds 2 >>>>> static inner classes for RemoteSolrException and >>>>> RemoteExecutionException which should find a new home somewhere. >>>>> Since they are referenced so much, that will happen only in main. >>>>> HttpSolrClientBase is a tempting home but SolrClient would be fine, I >>>>> think. >>>>> >>>>> Also, just because we have a nice new HttpJdkSolrClient, doesn't mean >>>>> we can yet advise anyone to safely remove Apache & Jetty dependencies >>>>> *yet*! We have no tests that this works, and a quick attempt I did >>>>> recently showed there are some obscure references still! Modularizing >>>>> SolrJ further (for Jetty & Apache) will help reveal where we have some >>>>> references, after which we can finally free users of needing those >>>>> dependencies. >>>>> >>>>> ~ David Smiley >>>>> Apache Lucene/Solr Search Developer >>>>> http://www.linkedin.com/in/davidwsmiley >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >> >> _______________________ >> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com >> <http://www.opensourceconnections.com/><http://www.opensourceconnections.com/> >> | My Free/Busy <http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> This e-mail and all contents, including attachments, is considered to be >> Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > <mailto:dev-unsubscr...@solr.apache.org> > For additional commands, e-mail: dev-h...@solr.apache.org > <mailto:dev-h...@solr.apache.org> _______________________ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
