lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Spatial contrib bug fixing
Date Tue, 24 Apr 2012 21:14:36 GMT
Great

The actual library lives outside of Lucene (
https://github.com/spatial4j/spatial4j ) and only some integration classes
are within the Lucene project itself. I linked to the (long) discussions
about this in my previous message. I will be following that approach with
this port, and really hope there will be no API differences I won't be able
to overcome.

I'm going to start doing this sometime tomorrow, but my main efforts will
be on Thursday. I can certainly use any help in dividing work etc - please
anyone who can join on Thursday for live collaboration or later chip in the
discussion.

I'll keep you posted.

On Wed, Apr 25, 2012 at 12:00 AM, Christopher Currens <
currens.chris@gmail.com> wrote:

> Yes, the contrib is a MESS.  I've been favoring complete re-implementations
> over porting changes, since contrib has been in such a poor, overlooked
> state for so long.
>
> I'm not opposed to porting LSP over the Spatial contrib project in Java,
> though it will might some porting challenges both now, since Lucene
> versions are different, and as Lucene.NET evolves.  It also might not, I'm
> not familiar with the LSP code.  Contrib is just that, contributed software
> that is not part of the core library, and there will be projects in Java we
> can't port over.  In fact, I think there are .NET specific contrib projects
> that aren't in java.  Either way, my point is that I'm am happy and willing
> to have LSP included if that's going to wind up being better than Spatial.
>  I think we can use all the help and contributions we can get in
> Lucene.NET.
>
> Of course, we'd need to look and see what is possible, with porting over
> LSP (not sure if it relies on any version specific features that may not
> yet be in 3.0.3).  So, I say let's go for it, and if you need any help/want
> to divide work between other committers, we can arrange that, and create
> issues for it, that is, if the other committers don't object to this.
>
> On Tue, Apr 24, 2012 at 1:45 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > Thanks for your reply.
> >
> >
> > >  Aside from the original port which had many divergences from java, the
> > > only other issue applied to spatial is LUCENENET-431, which would be
> easy
> > > to include.
> > >
> > >
> > That is not correct. LUCENENET-431 was committed, but some fixed from
> Java
> > Lucene 3.0.3 are in as well. The whole thing is a mess.
> >
> > The reason for this mess is the amount of bugs in the original Java
> > implementation of Spatial. This is also why it has been deprecated in
> 3.6:
> > https://issues.apache.org/jira/browse/LUCENE-2599
> >
> > I think the best route at this point is to port LSP aka Spatial4j to .NET
> > and start using it as the Spatial module for Lucene.NET
> > https://issues.apache.org/jira/browse/LUCENE-3795
> >
> > This is a Java Lucene 4 feature, but the current spatial implementation
> is
> > pretty unisable.
> >
> > I'm going to start looking into this, and would definitely appreciate
> your
> > input.
> >
> > Itamar.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message