[
https://issues.apache.org/jira/browse/SOLR-3295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242340#comment-13242340
]
Jan Høydahl commented on SOLR-3295:
-----------------------------------
bq. The problem is, the tika-parser list is in META-INFO of tika-parsers.jar.
To override it, you must disable the META-INF completely and list the parsers
in program code when calling TIKAs ctors... I can upload our (unedited example
code here).
Yes, they use the ServiceProvider mechanism, so that each JAR providing Tika
parser(s) have a META-INF/services/org.apache.tika.parser.Parser and it will
register itself when on classpath. I agree that if the parsers were in many
small JARs we could simply choose which ones to include and all would be fine.
Then, Solr users could simply add a parser JAR to classpath to get support for
a new format.
> Binaries contain 1.6 classes
> ----------------------------
>
> Key: SOLR-3295
> URL: https://issues.apache.org/jira/browse/SOLR-3295
> Project: Solr
> Issue Type: Bug
> Reporter: Dawid Weiss
> Assignee: Robert Muir
> Priority: Minor
> Fix For: 3.6
>
> Attachments: output.log
>
>
> I've ran this tool (does the job): http://code.google.com/p/versioncheck/ on
> the checkout of branch_3x. To my surprise there is a JAR which contains Java
> 1.6 code:
> {noformat}
> Major.Minor Version : 50.0 JAVA compatibility : Java 1.6
> platform: 45.3-50.0
> Number of classes : 60
> Classes are :
> c:\Work\lucene-solr\.\solr\contrib\extraction\lib\netcdf-4.2-min.jar [:]
> ucar/unidata/geoloc/Bearing.class
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
