[
https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190728#comment-17190728
]
Alexandre Rafalovitch commented on SOLR-13973:
----------------------------------------------
Sanity check on the links and numbers (I use both Drupal 8/9 and Solr, though
not currently together):
1) [https://www.drupal.org/project/apachesolr] is for Drupal 7 and before.
Those people will also continue using Solr 4 or whatever was the configuration
last updated to (2 years ago at the latest)
2) [https://www.drupal.org/project/search_api_solr] starting from v4 release
does support Drupal 8.8+/9 (only) and Solr versions more recent than Solr 6.4.
It was released in May 2020 and updated since. The current adoption is probably
still fairly low, but will accelerate next year, once previous release version
is no longer supported (notice said December).
Drupal was never known for chasing latest Solr version as they have their own
configuration that is designed for field definitions with wildcards and maybe
only recently (if at all) with managed-schema API manipulation. They can also
can keep using Solr 8 for another 5-6 years with Tika built in.
If Tika is removed from Solr (in version 9 the earliest), this will only affect
the choices of those setting up new Drupal installation and wanting new
features of Solr 9. At that point (say in 4 years), we can figure something out
for Solr 11. Most likely a variation on preconfigured Solr and Tika colocated
in a Docker container.
On the other hand, I honestly don't know much about solarium library directly.
Perhaps it is a serious issue there, though we have to look again at number of
active installations*percentage of those using /extract handler*percentage of
people able to run _latest_ Solr process but not a second (also Java) process.
So, to me, this sounds less like a -1, then as an awareness for a bit of an
extra education around that edge case. And, yes, awareness of the greater
community; something we really need to pay more attention to in general.
Of course, any improvement of workflow we can do between Solr and Tika, both
standalone, would be very good regardless of this particular use case.
> Deprecate Tika
> --------------
>
> Key: SOLR-13973
> URL: https://issues.apache.org/jira/browse/SOLR-13973
> Project: Solr
> Issue Type: Improvement
> Reporter: Ishan Chattopadhyaya
> Assignee: Ishan Chattopadhyaya
> Priority: Blocker
> Fix For: 8.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Solr's primary responsibility should be to focus on search and scalability.
> Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us
> down. I propose that we deprecate it going forward.
> Tika can be run outside Solr. Going forward, if someone wants to use these,
> it should be possible to bring them into third party packages and installed
> via package manager.
> Plan is to just to throw warnings in logs and add deprecation notes in
> reference guide for now. Removal can be done in 9.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
