From general-return-2082-apmail-lucene-general-archive=lucene.apache.org@lucene.apache.org Mon Mar 01 08:29:43 2010
Return-Path:
Delivered-To: apmail-lucene-general-archive@www.apache.org
Received: (qmail 78870 invoked from network); 1 Mar 2010 08:29:43 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
by 140.211.11.9 with SMTP; 1 Mar 2010 08:29:43 -0000
Received: (qmail 97632 invoked by uid 500); 28 Feb 2010 18:55:42 -0000
Delivered-To: apmail-lucene-general-archive@lucene.apache.org
Received: (qmail 97610 invoked by uid 500); 28 Feb 2010 18:55:42 -0000
Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: general@lucene.apache.org
Delivered-To: mailing list general@lucene.apache.org
Received: (qmail 97602 invoked by uid 99); 28 Feb 2010 18:55:42 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 18:55:42 +0000
X-ASF-Spam-Status: No, hits=-1.8 required=10.0
tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [128.149.139.105] (HELO mail.jpl.nasa.gov) (128.149.139.105)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 18:55:31 +0000
Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72])
by smtp.jpl.nasa.gov (Switch-3.4.2/Switch-3.4.1) with ESMTP id o1SIt8GV024994
(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL)
for ; Sun, 28 Feb 2010 10:55:08 -0800
Received: from ALTPHYEMBEVSP20.RES.AD.JPL ([172.16.0.21]) by
ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Sun, 28 Feb 2010
10:55:08 -0800
From: "Mattmann, Chris A (388J)"
To: "general@lucene.apache.org"
Date: Sun, 28 Feb 2010 10:55:06 -0800
Subject: Re: Factor out a standalone, shared analysis package for
Nutch/Solr/Lucene?
Thread-Topic: Factor out a standalone, shared analysis package for
Nutch/Solr/Lucene?
Thread-Index: Acq4pWIyngPoZUzhQruHiAd7YM4lHgAAiiLJ
Message-ID:
In-Reply-To: <4B8AB847.3030000@gmail.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative;
boundary="_000_C7AFFC0AD1F5ChrisAMattmannjplnasagov_"
MIME-Version: 1.0
X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72]
X-Source-Sender: chris.a.mattmann@jpl.nasa.gov
X-AUTH: Authorized
X-Virus-Checked: Checked by ClamAV on apache.org
--_000_C7AFFC0AD1F5ChrisAMattmannjplnasagov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Mark,
Thanks for the feedback. My concern is that if the two communities are pret=
ty separate, then it is going to be more difficult merging them, and it's n=
ot always a good thing to take separated modules (or communities) and integ=
rate them into a monolith, whether it be physically in the code, or communi=
ty-wise. I and a bunch of others learned the hard way in OODT-ville at NASA=
, and we moved towards a more loosely coupled solution, even at the expense=
of the difficulty in "being out of date" from time to time. This experienc=
e makes it difficult for me to support such a move...
Thanks!
Cheers,
Chris
On 2/28/10 10:39 AM, "Mark Miller" wrote:
On 02/28/2010 12:52 PM, Michael Busch wrote:
> ... I think it's a good
> idea for SOLR to ride on Lucene's trunk again...
> However, I'm -1 for these points:
>
> * When a change it committed to Lucene, it must pass all Solr tests.
> * Release both at once.
>
>
These are huge reasons why we *don't* want SOLR to ride on Lucene's
trunk anymore.
bq. but we have to ask why they weren't added to Lucene in the first place.
Because the two communities are fairly separate in a lot of ways. This
is one of the things a potential merge would solve. We can say that the
projects should communicate more all we look - the history of saying
such things implies there will be no changes though.
I'm still +0 here, but I'm starting to lean towards merge just sitting
here disagreeing with everyone arguing against :)
Solr is actually part of the project "Lucene" along with Lucene-Java.
The divide now is actually almost unnatural considering how things
are organized.
To those arguing that this would make Solr a first class citizen of
Lucene over other search solutions that use Lucene, that actually
already is the case, and the way things are setup, it should be. Solr is
part of the Lucene project. Other Lucene search engines are not. That
doesn't mean we shouldn't consider Lucene changes in the context of all
the projects that may use it, but Solr already is a first class citizen.
Its not just some project using Lucene - its *the* Lucene project's
Search Server. Lucene devs *should* consider Solr when developing on
Lucene Java - they are the same project - Lucene.
--
- Mark
http://www.lucidimagination.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
--_000_C7AFFC0AD1F5ChrisAMattmannjplnasagov_--