[ 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:11 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/ _@lucene.internal_ 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? 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 2. Move {{LatLonShape}}, {{XYShape}}, queries and supporting classes to spatial module; make dependency classes in core public and label w/ _@lucene.internal_ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org