[
https://issues.apache.org/jira/browse/LUCENE-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422164#comment-13422164
]
Uwe Schindler commented on LUCENE-4044:
---------------------------------------
One thing for later cleanup (I just add these points here to add further
subtasks to parent issues once this is committed): Solr/contrib/analysis-extras
is now almost obsolete and feels - it only contains a standalone lib/ folder
and one single class ICUCollationKeyField.java. We should nuke that and maybe
find a good solution for the CollationKeyField (copy to core?, use Reflection,
so it only works with ICU when available,...).
With the current approach you can simply copy the JAR files from the advanced
analyzers in Lucene to your solr/lib plugin folder and they are available
(depending on solrconfig.xml, of course). That's the most cool thing on the
whole issue! No need to ship them with distribution, maybe add a downloader
script to Solr that fetches the required JARS from maven/ivy and install them
in you Solr instance's lib folder.
> Add NamedSPILoader support to TokenizerFactory, TokenFilterFactory and
> CharFilterFactory
> ----------------------------------------------------------------------------------------
>
> Key: LUCENE-4044
> URL: https://issues.apache.org/jira/browse/LUCENE-4044
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: modules/analysis
> Reporter: Chris Male
> Fix For: 4.0
>
> Attachments: LUCENE-4044-stripped.patch, LUCENE-4044.patch,
> LUCENE-4044.patch
>
>
> In LUCENE-2510 I want to move all the analysis factories out of Solr and into
> the directories with what they create. This is going to hamper Solr's
> existing strategy for supporting {{solr.*}} package names, where it replaces
> {{solr}} with various pre-defined package names. One way to tackle this is
> to use NamedSPILoader so we simply look up {{StandardTokenizerFactory}} for
> example, and find it wherever it is, as long as it is defined as a service.
> This is similar to how we support Codecs currently.
> As noted by Robert in LUCENE-2510, this would also have the benefit of
> meaning configurations could be less verbose, would aid in fully decoupling
> the analysis module from Solr, and make the analysis factories easier to
> interact with.
--
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]