[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693221#comment-16693221
]
Tomoko Uchida commented on LUCENE-8566:
---------------------------------------
I'm not sure if I can complete the whole to-do list, but getting one or two
things done should still be good for users and for this project. :)
I will create the patch for each task (one by one) and let you know.
{quote} - Officially document the SPI names
- Don't derive the SPI names from class name anymore (we should put them into
the classes as static final constants). By that you can add compile time safety
again (user can do FooBarFactory.NAME).
- Replace the solr examples in javadocs by generic ones that use SPI names
- Change Solr to allow "name=...." instead of "class=..." for analyzer
configs.{quote}
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> ----------------------------------------------------------------------
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
> Reporter: Tomoko Uchida
> Assignee: Uwe Schindler
> Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class<? extends TokenizerFactory> factory, String... params)
> - withTokenizer(Class<? extends TokenizerFactory> factory,
> Map<String,String> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory, String...
> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory,
> Map<String,String> params)
> - addCharFilter(Class<? extends CharFilterFactory> factory, String... params)
> - addCharFilter(Class<? extends CharFilterFactory> factory,
> Map<String,String> params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
