I love this idea.! Bill Bell Sent from mobile
On Apr 6, 2011, at 2:39 PM, Grant Ingersoll <[email protected]> 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?) 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
