lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-3848) dataimporthandler-extras depends on Tika but doesn't have it in it's ivy deps
Date Mon, 17 Sep 2012 19:48:07 GMT

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message