Did we want to try and remove Tika (and it’s long list of dependencies) from Solr 9? The Tika 2.0 project provides a much lighter way of integrating Tika that could be used in Solr….
> On Oct 22, 2021, at 6:13 PM, Houston Putman <[email protected]> wrote: > > Dont want to start a bike shed here, but on the v2 api topic, I am not in > support of deprecation/removal yet. Beyond the support not being universal, I > think there are a good number of V2 apis that are worse than the v1 apis. I > think if we really want to remove v1 we need to go take another look, come up > with a consistent pattern across the project and then create a v3 that makes > more sense. Currently I dont see the v2 api as a livability improvement over > v1. > > - Houston > > 2021년 10월 22일 (금) 오후 5:37, Jan Høydahl <[email protected] > <mailto:[email protected]>>님이 작성: > Marcus, there are two different things being discussed here - Http2Client and > V2Api. Jason commented on the V2-Api part.is <http://part.is/> there an > umbrella Jira with open subtasks for every Api that is not covered in V2? > > Jan Høydahl > >> 22. okt. 2021 kl. 22:57 skrev Marcus Eagan <[email protected] >> <mailto:[email protected]>>: >> >> > >> Jason, You raise a good point. Can you elaborate on the "big gap" in the >> ticket? >> >> The only one I saw in there was DelegationTokenHttpSolrClient, and that is >> deprecated itself. I think it would be helpful to enumerate the gaps very >> clearly so that people can divide and conquer supporting them for v2. >> >> Marcus >> >> On Fri, Oct 22, 2021 at 12:39 PM Jason Gerlowski <[email protected] >> <mailto:[email protected]>> wrote: >> > Is it too early to deprecate V1 APIs in 8.11? >> >> I think so, unfortunately. The docs in particular have seen big >> strides in their v2 coverage, but the code itself still has a pretty >> big gap to close in terms of bringing the v2 APIs into parity with v1. >> A lot of v1 APIs have parameters that aren't exposed in the v2 >> equivalent, etc. If there was interest we could probably deprecate >> certain sections of our v1 API, but we're definitely not ready to do >> it across the board IMO. >> >> Jason >> >> On Fri, Oct 22, 2021 at 2:28 PM Gus Heck <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > The list seems to be missing >> > https://issues.apache.org/jira/browse/SOLR-14290 >> > <https://issues.apache.org/jira/browse/SOLR-14290> ? If that's not fixed >> > folks who have used our test framework for their own tests will have >> > issues. >> > >> > On Fri, Oct 22, 2021 at 11:27 AM Jan Høydahl <[email protected] >> > <mailto:[email protected]>> wrote: >> >> >> >> Yep, that is a more precise description :) >> >> >> >> Is it too early to deprecate V1 APIs in 8.11? There has been some great >> >> effort to get the v2 APIs up to date lately. >> >> Perhaps for 9.0 it is enough to use V2 in all tutorials and ref-guide, >> >> and also Admin UI. And then deprecate v1 in 9.x and remove in 10.0 >> >> >> >> Jan >> >> >> >> 22. okt. 2021 kl. 04:01 skrev David Smiley <[email protected] >> >> <mailto:[email protected]>>: >> >> >> >> Thanks for the reminder; I'll get to some of these slowly after the 8.11 >> >> feature-freeze. >> >> >> >> Note that in SOLR-15223, the point is not "HTTP1 deprecation", it's >> >> deprecating one of our two HTTP clients. The one we are keeping (Jetty >> >> client) can talk HTTP1 (and it will if it talks to older Solr servers) -- >> >> that isn't deprecated. >> >> >> >> ~ David Smiley >> >> Apache Lucene/Solr Search Developer >> >> http://www.linkedin.com/in/davidwsmiley >> >> <http://www.linkedin.com/in/davidwsmiley> >> >> >> >> >> >> On Thu, Oct 21, 2021 at 9:19 AM Jan Høydahl <[email protected] >> >> <mailto:[email protected]>> wrote: >> >>> >> >>> Hi, >> >>> >> >>> The Lucene 9.0 release is starting to materialize with a clearn timeline >> >>> for v8.11 as the last 8.x and then 9.0 immediately after. >> >>> >> >>> We should start preparing for Solr 9.0 by updating the list of real >> >>> blockers and decide which of those require commits in 8.x (deprecations, >> >>> preparation for upgrade compat). >> >>> >> >>> Here's the current blocker list for Solr: >> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%22main%20(9.0)%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC >> >>> >> >>> <https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%22main%20(9.0)%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC> >> >>> >> >>> <Skjermbilde 2021-10-21 kl. 15.16.06.png> >> >>> >> >>> Please review these. I think several can be closed as unrealistic, and >> >>> probably new ones can be added. I have started looking at HTTP1 >> >>> deprecation in SOLR-15223. >> >>> >> >>> >> >>> Jan >> >> >> >> >> > >> > >> > -- >> > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) >> > http://www.the111shift.com <http://www.the111shift.com/> (play) >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> >> >> >> -- >> Marcus Eagan >> _______________________ Eric Pugh | Founder & CEO | 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.
