[
https://issues.apache.org/jira/browse/LUCENE-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421151#comment-13421151
]
Robert Muir commented on LUCENE-4044:
-------------------------------------
{quote}
Absolutely. I'm a huge fan of the simplified syntax.
{quote}
I think so too, but since some of this is contentious, lets just leave it for a
future issue.
Basically we can use the SPI to implement backwards compat, but in the future
we can imagine more:
* remove .java Analyzer files from lucene and replace with some declarative
specification that uses the factories (e.g. json or whatever)
* fix TestRandomChains or whatever to use SPI to find available tokenstreams,
fix it to be a real integration test too.
* allowing users to pick from available implementations in analysis gui to
prototype up a chain and see what it looks like
* simplified syntax as mentioned above
Those were just my ideas. we can just leave these for future issues.
On this issue we can make the pluggability simple, improve testing, make sure
backwards is done right, and get it all past the generics policeman :)
> 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.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]
