[SOLR-3848] dataimporthandler-extras depends on Tika but doesn't have it in it's ivy deps

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Won't Fix
• Component/s: contrib - DataImportHandler
• Assignee: Unassigned
• Reporter: Chris M. Hostetter
• Created: 17/Sep/12 19:16
• Updated: 29/Aug/20 18:42
• Resolved: 29/Aug/20 18:42

Description

Noticed this while dealing with SOLR-3759...

• solr/contrib/dataimporthandler-extras contains MailEntityProcessor and TikaEntityProcessor
• both of these classes have acompile & runtime dependency on org.apache.tika.*
• solr/contrib/dataimporthandler-extras/ivy.xml does not mention any external dependencies
• solr/contrib/dataimporthandler-extras/build.xml has a "resolve-extraction-libs" to force solr/contrib/extraction to fetch it's deps so that dataimporthandler-extras can use them directly
• solrconfig.xml files in example-DIH point to the contrib/extraction/lib/ dir to get the Tika dependencies for demo purposes

I believe this is all intentional so that we don't have two copies of all the tika jars floating around, particularly in the binary releases, but even though i'm one of the people who was involved in setting things up this way in dataimporthandler-extras/build.xml, it still confused/surprised me...

https://svn.apache.org/viewvc?view=revision&revision=1307563
https://svn.apache.org/viewvc?view=revision&revision=1309503

I think at a minimum, we should probably add some comments to dataimporthandler-extras/ivy.xml about this kludge, and probably call it out more in the various example-DIH/*/solrconfig.xml files as well. That said: If anyone feels strongly that we should "fix" this so that dataimporthandler-extras/ivy.xml explicitly fetches the tika deps - please speak up.

Issue Links

• is superceded by: SOLR-14783 Remove DIH from 9.0