lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7056) Spatial3d/Geo3d should have zero runtime dependencies
Date Tue, 01 Mar 2016 16:37:18 GMT


David Smiley commented on LUCENE-7056:

bq. +1 from someone who is just started looking at this stuff. I think we need to keep this
stuff as simple as possible. Exposing a bunch of unnecessary API makes things much more difficult.
We've applied a similar approach to the other point classes already.

Can you please explain how leaving it exposed (public) makes things "much more difficult"?
 Or maybe you don't mean more difficult but just less "simple" by virtue of people seeing
it and being confused by cognitive overload of stuff they won't need?  If it's the latter
and not difficulty in something else then I think keeping purely the geometries separated
and even better, out of Lucene, helps.  Keeping it package private would help too at the determent
of others who want to use this, and it would foster the continuation of this very large Java
package growing without organization.  One of the biggest annoyances I have with it is that
each time I look in there I have to figure out which of these classes are the Lucene ones.
 It's taken me an embarrassingly long time on occasion to the point that I've resorted to
my IDE's dependency analyzer to tell me which are the Lucene ones.  _Even if we don't agree
to the entire aims of this issue, I'd like to to consider separating these 2 classes out by
package.  What do you think about that specifically?_

bq. If someone wants the geo3d math implemenation, alone, they can poach/fork from us?

Because that's a large barrier to sharing / re-use.  it's easy for you to suggest this, living
in the code base that has it, but please consider an outsider.  :-( Hearing this suggestion
makes me sad; and the idea of making it all package private even sadder.

bq. Lucene shouldn't try to be in the business of "exporting spatial math libraries for others
to use". We are a search engine, and our priorities here are to make spatial indexing and
searching work well.

Then why is Geo3d/Spatial3d even here at all?  I'd rather it not be but I'm not pushing for
that today; just a compromise.  Keep it here while it suits us.  You've made the point that
it's easier/faster to iterate on Geo3d here and I recognize that, so leave it here.  Some
day we will look back and see it has stabilized, and I hold out some fleeting hope you might
be convinced in the merits of a dependency instead of maintaining it here.  Not a dependency
from lucene-core or lucene-spatial, but lucene-spatial-extras.

bq. It's the same reason why we don't e.g. invest in making FSTs easier for outsiders to use:
these are internal data structures that we use to provide awesome indexing/searching.

I don't think these are mutually exclusive.  Of course there can be technical decisions that
trade off ease of use for performance and we'd rather choose performance in many cases, but
that doesn't mean it's a bad idea to expose a library that others might use.  If we were to
do so, we wouldn't have to be bound by annoyances like backwards compatibility if we chose
not to.  Part of the thrill I get in contributing to open-source is knowing my code is used
so widely, and hearing kind remarks of its usefulness.  Don't you?

bq. Actually 5.x also has the classes for Lucene users to index and search with geo3d, under
the org.apache.lucene.bkdtree3d package in the spatial3d module.

Oh yeah; I overlooked that for some reason; weird.

> 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