[
https://issues.apache.org/jira/browse/LUCENE-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315820#comment-15315820
]
Michael McCandless commented on LUCENE-7314:
--------------------------------------------
bq. Mike: Sorry but I see this quite different than codecs.
I think you only say that because that is in fact the status quo. It could
just as easily (by your logic) go the other way, and our best codec would be in
the codec modules, and when you use Lucene you must go and pick a codec, just
like you must go and pick a highlighter or query parser or spatial search from
their modules today.
I feel this approach, that all functions must be moved into all modules,
defeats direct users of Lucene. Sure, those of us working on ES and Solr will
always know where things wind up (we pay close attention here), and we will
figure out how to expose things, but direct users see spatial modules with tons
of choices and it's not clear which is a good "default" starting option.
Likewise for highlighters, queryparsers and spatial search (this issue).
Lucene becomes harder to use when we hide the good defaults like this.
Anyway, I'll stop ranting now! It looks like I'm outvoted here, and we should
just hide these two good classes away in spatial and misc modules.
> Graduate InetAddressPoint and LatLonPoint to core
> -------------------------------------------------
>
> Key: LUCENE-7314
> URL: https://issues.apache.org/jira/browse/LUCENE-7314
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
>
> Maybe we should graduate these fields (and related queries) to core for
> Lucene 6.1?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
