lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: [POLL] JTS compile/test dependency
Date Wed, 06 Apr 2011 18:39:16 GMT

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?) could then go and implement that provider using JTS and can easily
leverage all of our existing tests as well as it's own (using the handy-dandy test framework).
 Users who wish to use this would then simply include the external JAR (accepting that it
is LGPL on their own free will) and telling L/S to use a different Provider.  I thought this
is what you already proposed.  This allows innovation on our stuff (which may well surpass
JTS at some point) as well as satisfies the short term win of JTS w/o violating ASF legal
issues (per  It would also make
it easy for SIS to add it's own provider if and when it is mature enough.


On Apr 6, 2011, at 2:12 PM, Ryan McKinley wrote:
> [] OK with JTS compile dependency.  Spatial support should be a module
> [] OK with JTS, but think this spatial stuff should happen elsewhere
> [] Please, no LGPL dependencies in lucene build

[x] Please no LGPL in Lucene build, please keep spatial framework here, please implement JTS
piece in Apache Extras per a well-defined (and hosted in Lucene) SpatialProvider/Factory mechanism
that is completely pluggable.  Compile dependency is in JTS needs Lucene spatial module, not
Lucene spatial module needs JTS.  :-)

View raw message