lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <>
Subject Re: Lucene Spatial Future
Date Tue, 05 Apr 2011 14:30:14 GMT
On Tue, Apr 5, 2011 at 9:34 AM, Grant Ingersoll <> wrote:
> On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
> In the days of sub-projects, I would have proposed that option, but
> now I see two options:
> A.  Work on spatial lucene outside of apache -- perhaps osgeo or even
> just github. (would need a different name)
> B.  Allow JTS compile-time dependency in lucene, and move spatial
> contrib to a real module
> What about C:  Spatial in Lucene/Solr w/ JTS component in Apache Extras as a
> drop in jar that implements the appropriate bindings?  I personally have an
> interest in good spatial in L/S including more than just point search.  This
> solution need not require any automated downloads/compiles, etc. and it can
> be noted that the support of that particular jar is handled on Apache Extras
> (or Githup or wherever)

If the suggestion is splitting the build so that the JTS shapes and
math are not tested with the core, then i am -1

The spatial build and test system should be designed to best test
spatial -- without jumping through serious hoops, splitting the
compile/test setup only hurts the project.  (unless you don't really
care about the more complex stuff....)

I also want to make sure that the concerns of more complex features
are a top priority of the whole framework -- developing/patching
across two repos stinks.

> Alternatively, has anyone simply asked JTS if they would dual license or
> something like that?  I'm happy to do that, but let's coordinate so that we
> aren't all bombarding the guy.

You can always ask... but I think it is too late for a license change.
 This has been around to 10 years and the original copyright owner
appears to be a defunct company.  (note

Also check:

> I think option A is better long term, but I feel like the kid saying
> "if I can't have my way I'll take my ball (code) and go home"  -- i
> don't want this to sound like an ultimatum, but an honest discussion
> about what has the best chance of fostering a thriving development
> community.
> I personally don't.  I think we have enough committers who are active on
> spatial that we can sustain it once we have a good foundation in place
> (which we are close to) and we also have several contributors who have been
> active on spatial and are likely good candidates for being committers to
> work on it.

Right now the lucene umbrella is pretty big -- the dev concerns of
spatial are, and *should* be, of little concern to the core lucene
development.  I think spatial dev should live in a place where the
spatial concerns are top priority.

Just because it uses lucene does not mean it needs to be in the lucene umbrella.

Perhaps moving the whole thing to apache-extras is OK, but that is not
a visible place to attract participation etc.  osgeo seems like a
natural home since it will attract more spatial developers.

Other then status quo... why should this live in the lucene repo?


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

View raw message