Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of ryantxu@gmail.com designates
 74.125.82.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=AnUr1RYe8ne5yKZir+gcICixe2LenE5NR00GW3QvR8gSVX63mf4BIXQ7gZuWijAhL0
         PK9YrsCIC/tQsB0RYradHePbqJkgvRLsohBsiA2Z9DvzYuvlRFG8P0b79bhEJP90+Swq
         /fZa0FEDczmCO1u2PSSg4NAuKXlT9QsRibzQE=
MIME-Version: 1.0
In-Reply-To: <DFF7A7A0-F5AF-4F7B-875B-3B54C7F65BD2@gmail.com>
References: <BANLkTiniNJ0qzGCqK5CYLOSZskdDirYRpA@mail.gmail.com>
	<DB978AE3-44AC-4963-BC5D-13C5840EC81A@apache.org>
	<BANLkTincFvtMeUyxym0y6DNtsqrqpbiqFQ@mail.gmail.com>
	<DFF7A7A0-F5AF-4F7B-875B-3B54C7F65BD2@gmail.com>
Date: Wed, 6 Apr 2011 15:12:44 -0400
Message-ID: <BANLkTimDcDD0ReX23zDdO+GDUwvs=Jxt8g@mail.gmail.com>
Subject: Re: [POLL] JTS compile/test dependency
From: Ryan McKinley <ryantxu@gmail.com>
To: dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 6, 2011 at 2:48 PM, Grant Ingersoll
<grant.ingersoll@gmail.com> wrote:
>
> On Apr 6, 2011, at 2:44 PM, Ryan McKinley wrote:
>
>> On Wed, Apr 6, 2011 at 2:39 PM, Grant Ingersoll
>> <grant.ingersoll@gmail.com> 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. =A0We have our own implementation of that which works =
for
>>> some set (or all) of the features. =A0 An external project (Apache Extr=
as?)
>>
>> This is the non-starter for me. =A0This would split the dev across
>> multiple places and mean that the implementations I use (JTS) would
>> not be a first class citizen in testing.
>>
>> This is the point of the whole debate... and why i think elsewhere may
>> be a better option.
>
>
> That's a bit contradictory, though, isn't it? =A0By definition, elsewhere=
 means split too,

I'm looking at the proposed spatial strategy stuff as a unit.  It is
obviously related to existing stuff, but is a very different thing.


> b/c we have stated the point search stuff isn't going anywhere.

Agree -- i think the two would live happily together.  Parts of
existing point stuff may be deprecated if that seems appropriate. But
other parts -- especially the general vector based function queries
would never map to a high level spatial API anyway.


>And even if it does, you will still need to have a separate factory based =
implementation and ship a non-JTS provider, otherwise none of it can be pac=
kaged into a L/S release, so it's still the same amount of work.

IIUC, we can distribute classes that were compiled against the JTS
API, but not JTS itself.  People could register what provider should
get used and if JTS is available, it would load that one via
reflection.

ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org