lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <>
Subject Re: [POLL] JTS compile/test dependency
Date Wed, 06 Apr 2011 19:12:44 GMT
On Wed, Apr 6, 2011 at 2:48 PM, Grant Ingersoll
<> wrote:
> On Apr 6, 2011, at 2:44 PM, Ryan McKinley wrote:
>> On Wed, Apr 6, 2011 at 2:39 PM, Grant Ingersoll
>> <> wrote:
>>> I don't see why we need a compile/test dependency is needed at all:
>>> We provide a factory based spatial module where one specifies a
>>> SpatialProvider.  We have our own implementation of that which works for
>>> some set (or all) of the features.   An external project (Apache Extras?)
>> This is the non-starter for me.  This would split the dev across
>> multiple places and mean that the implementations I use (JTS) would
>> not be a first class citizen in testing.
>> This is the point of the whole debate... and why i think elsewhere may
>> be a better option.
> That's a bit contradictory, though, isn't it?  By definition, elsewhere means split

I'm looking at the proposed spatial strategy stuff as a unit.  It is
obviously related to existing stuff, but is a very different thing.

> b/c we have stated the point search stuff isn't going anywhere.

Agree -- i think the two would live happily together.  Parts of
existing point stuff may be deprecated if that seems appropriate. But
other parts -- especially the general vector based function queries
would never map to a high level spatial API anyway.

>And even if it does, you will still need to have a separate factory based implementation
and ship a non-JTS provider, otherwise none of it can be packaged into a L/S release, so it's
still the same amount of work.

IIUC, we can distribute classes that were compiled against the JTS
API, but not JTS itself.  People could register what provider should
get used and if JTS is available, it would load that one via


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

View raw message