tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Krugler (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (TIKA-514) Provide constructor for AutoDetectParser that has explicit list of supported parsers
Date Tue, 14 Sep 2010 17:00:34 GMT

     [ https://issues.apache.org/jira/browse/TIKA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ken Krugler resolved TIKA-514.
------------------------------

    Resolution: Fixed

Committed: http://svn.apache.org/viewvc/?rev=996984

> 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
>
>         Attachments: TIKA-514.patch
>
>
> 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.


Mime
View raw message