[ 
https://issues.apache.org/jira/browse/TIKA-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901180#action_12901180
 ] 

Jan Høydahl commented on TIKA-490:
----------------------------------

Either solution is OK by me.

But from my experience classpath problems in application servers can cause a 
headache, and therefore I tried to be as explicit as possible.

It would of course work to put a tika.language.properties file on classpath as 
well, if you know it's earlier in classpath than the tika jar.

Or we could name the jar-internal properties file 
tika.language.default.properties, and let people override through 
tika.language.properties :)

I'll leave the decision up to you. Remove the override if you feel strong about 
it.

> Support for adding language profiles dynamically
> ------------------------------------------------
>
>                 Key: TIKA-490
>                 URL: https://issues.apache.org/jira/browse/TIKA-490
>             Project: Tika
>          Issue Type: Improvement
>          Components: languageidentifier
>    Affects Versions: 0.7
>            Reporter: Jan Høydahl
>            Assignee: Chris A. Mattmann
>             Fix For: 0.8
>
>         Attachments: TIKA-490.Mattmann.082210.patch.txt, TIKA-490.patch, 
> TIKA-490.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Currently the Tika LanguageIdentifier loads language profiles thorugh a 
> hardcoded static block in the java code.
> It would be better to make this configurable, so you could add your own 
> languages without recompiling.
> Suggested approach:
> Remove the static code block loading all languages. Instead look for a 
> tika.languageidentification.properties file on classpath.
> Now the user can simply make his/her own (additional) language profile files, 
> put them on the classpath together with a properties file and off you go!
> Also, once you make it configurable, there might be an issue of having the 
> profiles as static members, as you will force the same behaviour for the 
> whole VM. A static Map of Maps could solve this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to