lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7056) Spatial3d/Geo3d should have zero runtime dependencies
Date Thu, 03 Mar 2016 04:45:18 GMT


Robert Muir commented on LUCENE-7056:

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

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

> Spatial3d/Geo3d should have zero runtime dependencies
> -----------------------------------------------------
>                 Key: LUCENE-7056
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message