[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692863#comment-16692863
]
Uwe Schindler commented on LUCENE-8566:
---------------------------------------
Hi,
originally the whole analyzer was only using the SPI names. That's as Tomoko
says "the correct way". The factory methods were added on request by many users
who wanted to have compile-time safety. I agree with that, so we added the
factory builder methods. Indeed this allows to have at least compile checks on
the names, which makes it easier (for example) to write quick tests.
A second problem of the SPI names is currently that they are documented
nowhere. To figure them out, you have to know how they are derived from the
factory class name. Before doing anything like that here, we should:
- Officially document the factory names
- Replace the solr examples in javadocs by generic ones that use SPI names
- Change Solr to allow "name=...." instead of "class=..." for analyzer configs.
So I am -1 to remove them again.
> 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
> 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]
