[
https://issues.apache.org/jira/browse/TIKA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909324#action_12909324
]
Ken Krugler commented on TIKA-514:
----------------------------------
Just to capture all of the permutations, I'd proposed another solution, which
was to add a new TikaConfig() constructor that took a list of target Parser
classes (plus the classloader), thus avoiding the instantiation of unsupported
parsers that happened to be found on the classpath.
This would also require a new TikaConfig.setDefaultConfig() static method, and
the TikaConfig class would need to be immutable (for safety).
> Provide constructor for AutoDetectParser that has explicit list of supported
> parsers
> ------------------------------------------------------------------------------------
>
> Key: TIKA-514
> URL: https://issues.apache.org/jira/browse/TIKA-514
> Project: Tika
> Issue Type: Improvement
> Affects Versions: 0.7
> Reporter: Ken Krugler
> Assignee: Ken Krugler
> Fix For: 0.8
>
>
> To reduce the size of the Tika dependency chain, it's useful to exclude the
> supporting jars for types that don't need to process (e.g. Microsoft docs,
> PDFs, etc). This can easily remove 20MB of 3rd party jars.
> With 0.8-SNAPSHOT, the TikaConfig(Classpath) constructor now finds and
> instantiates all Parser-based classes found on the classpath. Which can
> trigger errors when 3rd party jars are missing.
> One solution, as proposed by Jukka, is to provide an alternative constructor
> for AutoDetectParser which includes the list of supported parsers, and avoids
> creating the default TikaConfig.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
