[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903204#comment-16903204
]
Nicholas Knize edited comment on LUCENE-8369 at 8/8/19 6:12 PM:
----------------------------------------------------------------
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module and maintain package private visibility on dependency
classes
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ [email protected]_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; keep core dependency class visibility package
private and use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to
expose package private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
was (Author: nknize):
As a side note: the two classes in the spatial module are no longer used and
can be removed; leaving the spatial module empty.
So it sounds like we're converging on three options then:
1. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to core;
delete spatial module and maintain package private visibility on dependency
classes
2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module; make dependency classes in core public and label w/ [email protected]_
3. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial
module for Lucene 9 release; leave core dependency class visibility alone and
use [java modules|https://www.jcp.org/en/jsr/detail?id=376] to expose package
private classes to the spatial module?
I introduce the third option here because a. I think it might strike a nice
balance between separating "esoteric" shape features (whatever that means) to
the spatial module while maintaining proper API visibility, and b. with the
move to Java 11 we can introduce the Java Platform Module system to achieve
proper visibility.
I'll admit I'm no expert when it comes to the Java Module System but I seem to
recall a conversation around this topic a few years back when Java 9 was
released?
> Remove the spatial module as it is obsolete
> -------------------------------------------
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
