FYI, I'm working on revamping lucene spatial in general https://lucene-spatial-playground.googlecode.com/svn/trunk/ http://code.google.com/p/lucene-spatial-playground/
These are just sketch APIs for now, but i hope to get them cleaned up and contributed soon. The proposal will be for 3 packages in /modules 1. spatial stuff w/o lucene dependencies -- shapes, distances, etc 2. lucene support for these types 3. solr support for the lucene stuff (4) demo, probably keep this as an external project since UI and demo stuff is much easier on the outside. I hope to migrate the existing spatial stuff to this structure and remove the not-really-working stuff. I'll post more when things are closer to commitable. ryan On Sat, Mar 26, 2011 at 11:12 AM, Robert Muir <[email protected]> wrote: > On Sat, Mar 26, 2011 at 11:03 AM, Yonik Seeley > <[email protected]> wrote: >> On Sat, Mar 26, 2011 at 9:48 AM, Yonik Seeley >> <[email protected]> wrote: >>> On Sat, Mar 26, 2011 at 7:32 AM, Robert Muir (JIRA) <[email protected]> wrote: >>>> I don't really think things like this (queries etc) should go into just >>>> Solr >>> >>> I disagree strongly with the sentiment that queries don't belong in Solr. >>> Everything developed in/for lucene need not be exported to Solr immediately. >>> Everything developed in/for solr need not be exported to Lucene immediately. >>> >>> If the work has been done, and the patch works for Solr, that should >>> be enough. Period. >> >> This is an important enough point that I'm going to follow it up with >> a quote from Mike: >> >> "The combined dev community would have no requirement/expectation that >> if someone adds something cool to Lucene they must also expose it in >> Solr. There will still be devs that wear mostly Solr vs most Lucene >> hats. There will also be devs that comfortably wear both. There will >> be devs that focus on analyzers and do amazing things ;)" >> >> We merged to *enable* moving code around easier, not to mandate it. >> It is wrong to object to a patch because someone hasn't done extra >> work with their solr hat on to enable it's use in solr. >> It is wrong to object to a patch because someone hasn't done extra >> work with their lucene hat on enable it's use in lucene. >> >> >> With that out of the way, let's get more specific: what "Query" in >> this patch should be moved, and to where? >> > > No, the question is: what justification is there for adding spatial > support to solr-only, leaving lucene with a broken contrib module, > versus adding it where it belongs and exposing it to solr? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
