lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Spatial contrib bug fixing
Date Tue, 24 Apr 2012 22:12:35 GMT
Before we start, I almost forgot, we need to make sure that it can actually
be ported into the project, according to ASF guidelines.  I *think* it
should be okay, because it's licensed under the Apache 2.0 license, but we
should get some feedback from our mentors, on whether this is okay.

Stefan, are there any problems with porting code from a non-apache project
that is licensed under the Apache 2.0 license?

On Tue, Apr 24, 2012 at 2:14 PM, Itamar Syn-Hershko <itamar@code972.com>wrote:

> 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