I see four in favor and none against in this DISCUSS thread. I would wish to see more engagement, but it is what it is.
Instead of initiating a new [VOTE] thread, let's instead let the actual PR that removes the feature be the (lazy) consensus for the code change itself, with ability to VETO as normal. But if you intend to veto such a change, better speak up now. Created a JIRA for this https://issues.apache.org/jira/browse/SOLR-18037 Jan > 16. des. 2025 kl. 17:54 skrev Tim Allison <[email protected]>: > > I'm still +1 on rm'ing Tika, but thought I'd chime in with some updates on > the newer forkparser. This will be in 4.0.0 to be released...at some point. > LOL... > > I've just added this module: > https://github.com/apache/tika/tree/main/tika-pipes/tika-pipes-fork-parser > > With examples: > https://github.com/apache/tika/blob/main/tika-example/src/main/java/org/apache/tika/example/PipesForkParserExample.java > > > > On Tue, Dec 16, 2025 at 11:41 AM Eric Pugh <[email protected]> wrote: > >> I don't know why it feels bad, but I suppose ;-). +1. I really hope >> someone steps up with a modern tika-pipes instead and gets that on 10. >> >> >> >> On 2025/12/12 18:45:16 Anshum Gupta wrote: >>> +1 on dropping local Tika extraction in 9.11. >>> >>> While it breaks our back-compat promise, its benefit of keeping users >>> secure clearly outweighs that. >>> >>> On Thu, Dec 11, 2025 at 4:50 PM Tim Allison <[email protected]> wrote: >>> >>>> Please don't ship anything with Tika 1.x. >>>> >>>> Jan, your work on slotting in tika-server is amazing. Please go forth >> with >>>> that, and consider 3.x at some point. :D >>>> >>>> On Thu, Dec 11, 2025 at 5:34 PM Jan Høydahl <[email protected]> >> wrote: >>>> >>>>> Hi, >>>>> >>>>> Tika 1.28 has been EOL since September 2022, and all its aging >>>>> dependencies, which we still ship in Solr 9.x, keep producing CVEs >> almost >>>>> weekly. >>>>> As Solr 9.10 has gained TikaServer support, I propose that we simply >>>>> declare "local" tika backend too old to ship and remove it in Solr >> 9.11. >>>>> >>>>> It will be a break from our normal back-compat promise. But I think >> it is >>>>> warranted in this case. >>>>> The alternative is to upgrade "local" Tika to 3.x, but that would be >> a >>>>> back-compat break as well (metadata), with no clear benefit over >>>> TikaServer. >>>>> >>>>> If this thread gains consensus I'll start a VOTE thread to formally >>>> decide >>>>> an exception. >>>>> >>>>> Jan >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>> >>> >>> -- >>> Anshum Gupta >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
