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 http://www.apache.org/legal/3party.html#options-optional). It would also make it easy for SIS to add it's own provider if and when it is mature enough.
-Grant 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. :-) -Grant
