[
https://issues.apache.org/jira/browse/SOLR-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3848:
---------------------------
Affects Version/s: (was: 4.0-BETA)
Fix Version/s: (was: 4.0)
Assignee: (was: Hoss Man)
I've commited hte comments i had in mind...
Committed revision 1386790.
Committed revision 1386792. -4x
But i'm leaving this issue open...
On IRC rmuir suggested that the "correct" fix for this would be to use the ivy
'conf' option with filename patterns so that the
dataimporthandler-extras/build.xml wouldn't need any special logic, and the
dataimporthandler-extras/ivy.xml could rever directly to the files in
../extraction/lib. So, if i understand correctly, dataimporthandler-extras's
ivy.xml would actually have the explicit list of jars that it wanted to fetch,
and "ant resolve" would fetch those jars w/o caring if contrib/extraction
built, but those jars would be fetched directly into extraction/lib.
leaving this issue open for further discussion/considering about this idea.
> dataimporthandler-extras depends on Tika but doesn't have it in it's ivy deps
> -----------------------------------------------------------------------------
>
> Key: SOLR-3848
> URL: https://issues.apache.org/jira/browse/SOLR-3848
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
> Reporter: Hoss Man
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
