[
https://issues.apache.org/jira/browse/LUCENE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177153#comment-15177153
]
Robert Muir commented on LUCENE-7056:
-------------------------------------
{quote}
So gents where does this leave us in terms of specific package naming to
separate them? I made a recommendation; do you like it?
org.apache.lucene.spatial.3d gets the 2 Lucene classes.
org.apache.lucene.spatial.3d.geom (most of the current code goes here; it
implements the geometries)
{quote}
Well i don't like this since {{3d}} is not a valid identifier in a java package.
Personally i would think it should be named {{org.apache.lucene.spatial3d}} and
{{org.apache.lucene.spatial3d.geom}}. Only because {{spatial3d}} is the
module's name, and this formula seems to be the only/easiest way to
scope/organize packages in our modules to prevent problems? Nearly all of our
modules are this way more or less, with the exception of {{misc}} and
{{sandbox}} which reuse packages like {{org.apache.lucene.index}} that really
belong to {{core}}. I think we should clean this stuff up for java 9 :)
As far as the additional module, i still don't personally agree with that, but
don't you think if we want to do that we still have to fix the java packages?
So basically I'm saying either way, we want to not have all of spatial3d/geo3d
piled in one package, so lets just start with that?
> Spatial3d/Geo3d should have zero runtime dependencies
> -----------------------------------------------------
>
> Key: LUCENE-7056
> URL: https://issues.apache.org/jira/browse/LUCENE-7056
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 6.0
>
>
> This is a proposal for the "spatial3d" module to be purely about the
> shape/geometry implementations it has. In Lucene 5 that's actually all it
> has. In Lucene 6 at the moment its ~76 files have 2 classes that I think
> should go elsewhere: Geo3DPoint and PointInGeo3DShapeQuery. Specifically
> lucene-spatial-extras (which doesn't quite exist yet so lucene-spatial) would
> be a suitable place due to the dependency. _Eventually_ I see this module
> migrating elsewhere be it on its own or a part of something else more
> spatial-ish. Even if that never comes to pass, non-Lucene users who want to
> use this module for it's geometry annoyingly have to exclude the Lucene
> dependencies that are there because this module also contains these two
> classes.
> In a comment I'll suggest some specifics.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
