Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 58845 invoked from network); 16 Nov 2009 23:44:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Nov 2009 23:44:46 -0000 Received: (qmail 43593 invoked by uid 500); 16 Nov 2009 23:44:46 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 43514 invoked by uid 500); 16 Nov 2009 23:44:45 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 43506 invoked by uid 99); 16 Nov 2009 23:44:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 23:44:45 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rcmuir@gmail.com designates 209.85.222.176 as permitted sender) Received: from [209.85.222.176] (HELO mail-pz0-f176.google.com) (209.85.222.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Nov 2009 23:44:41 +0000 Received: by pzk6 with SMTP id 6so4614548pzk.29 for ; Mon, 16 Nov 2009 15:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=0LjSKjLwmU4LIzlJ/B28uRYs0ObC/+Um07olsz/b5Ww=; b=nmkoYMSKd7rtwjfP07V7JkDkB83xnl3MlYdxqk1YqyusMIsi8vzdEo1mczDV3cz+FK 4iQmfv3kq6HuJ4tbi977Khh7aucALvLFbwtE8b7Xi0zfuYAnktvMX4NccG32fO9mdDza bv4mXLsAT0a7SOin61REx7UR+BsG+niRNMo6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=haxizmU/jlrRCVDA1FfCLtk8F+CZXaExiV43pVikvNx3GYfjpz35ASV+xuGKCrQCDa leO9RGxVFFzxLtJqUylOb8008pCOLgGIcyHZrUzereZSd/8fjQ6Yq4mG9hP2kwJJy/io fSIyKk8FCDpqW23d1p1LgBmsFkvs0/+rCd/B4= MIME-Version: 1.0 Received: by 10.115.66.35 with SMTP id t35mr9747115wak.87.1258415060773; Mon, 16 Nov 2009 15:44:20 -0800 (PST) In-Reply-To: <734E3FDF-A770-40C1-8AB4-2B288AAD7115@gmail.com> References: <359a92830911161010s2b04fe80s3c8b69b522518ca8@mail.gmail.com> <4B01B62A.6010405@gmail.com> <2868BFFF8B344E4A9761E7FAD2A3E09C@VEGA> <8f0ad1f30911161236p327a1475n93e2f2e6e9410711@mail.gmail.com> <4B01B9D9.4070003@gmail.com> <004FC8C5B7BE4CE3BC4DF0AD6340699A@VEGA> <9140F814C7E04A309F0852076320DEBB@VEGA> <8f0ad1f30911161336o2769b94fx4d23b70f48bb00c4@mail.gmail.com> <734E3FDF-A770-40C1-8AB4-2B288AAD7115@gmail.com> From: Robert Muir Date: Mon, 16 Nov 2009 18:43:59 -0500 Message-ID: <8f0ad1f30911161543n344957eobc5dcb88d14eb85b@mail.gmail.com> Subject: Re: Why release 3.0? To: java-dev@lucene.apache.org Content-Type: multipart/alternative; boundary=0016e64ce5b6addc7b047885966a --0016e64ce5b6addc7b047885966a Content-Type: text/plain; charset=UTF-8 DM, in this case I'm not referring to surrogates, etc, but instead the idea that properties for an existing character can change (the soft hyphen and arabic ayah were two examples), also new characters are introduced. these will affect what analysis components (ex. tokenizers) do, because they like to use categories such as .isWhiteSpace, .isLetter, things like that. this means these components have different behavior, because they are data-driven, even though we didnt change any code. On Mon, Nov 16, 2009 at 6:37 PM, DM Smith wrote: > I'm not sure that anyone is forced to go to Java 5. I think it is more that > some will be stuck on Java 1.4. My guess is that other than those that are > on a very old version of MacOSX (i.e. 10.3 aka Panther, Oct 2003-Apr 2005) > everyone else is using Java 5 or Java 6 already. > > Is core lucene really affected by the change? Or is it only contrib? I > mean, if we couldn't create an index using core with surrogate pairs and > other Unicode 4.0 stuff (though I'm not clear on the changes), how can it > change reading/searching the index? > > -- DM > > On Nov 16, 2009, at 4:36 PM, Robert Muir wrote: > > this fixes the standardTokenizer (thanks!!), but thats different, because > its not dependent on the end users JVM. > > i think we still need a warning to users, Mark opened an issue about it, > because other tokenizers are dependent on the end users JVM, and we are > forcing them to upgrade to 1.5 > > On Mon, Nov 16, 2009 at 4:33 PM, Uwe Schindler wrote: > >> I opened https://issues.apache.org/jira/browse/LUCENE-2074 >> >> It fixes the problem, the patch uses a different impl depending on >> matchVersion. >> >> If I commit it now, I would regenerate the rc1 artifacts and release the >> tomorrow to java-user. Currently the ones on people.apache.org are only >> "known" to java-dev users. >> >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: uwe@thetaphi.de >> >> >> > -----Original Message----- >> > From: Uwe Schindler [mailto:uwe@thetaphi.de] >> > Sent: Monday, November 16, 2009 9:59 PM >> > To: java-dev@lucene.apache.org >> > Subject: RE: Why release 3.0? >> > >> > OK, I checked. The JFLEX file in tunk was 1.4 generated. I regenerated >> > with >> > 1.5 and it was different (completely!). I saved the old version and >> > renamed >> > to StandardTokenizerImplJava14 extends StandardTokenizerImpl >> > >> > By this the impl is exchanged depending on version. The 1.4 version can >> no >> > longer be regenerated because it has no .jflex file and should really >> > never >> > be regenerated. >> > >> > ----- >> > Uwe Schindler >> > H.-H.-Meier-Allee 63, D-28213 Bremen >> > http://www.thetaphi.de >> > eMail: uwe@thetaphi.de >> > >> > > -----Original Message----- >> > > From: Mark Miller [mailto:markrmiller@gmail.com] >> > > Sent: Monday, November 16, 2009 9:45 PM >> > > To: java-dev@lucene.apache.org >> > > Subject: Re: Why release 3.0? >> > > >> > > I still reccomend we add a file then HowToRegenJflex.txt or something >> - >> > > that specifically says to use 1.5 or 1.6. I don't changing the current >> > > notice/warning is visible enough to ensure someone doesn't break this. >> > > >> > > Robert Muir wrote: >> > > > no. its still 4.0, but i hear 1.7 will be 5.1 or 5.2 >> > > > >> > > > the only way to truly control this, would be to use something like >> ICU >> > > > to control the unicode version being used (and actually be faster, >> and >> > > > support higher version). >> > > > see http://site.icu-project.org/home/why-use-icu4j >> > > > >> > > > the issue is that lucene does not have 3rd party library >> dependencies, >> > > > on the other hand, i think tika and/or nutch already incorporate icu >> > > > for charset detection. >> > > > >> > > > i won't argue for this really, i know nobody wants it, but you can >> see >> > > > how the situation of not being able to control unicode semantics is >> > > > really difficult for a search engine. >> > > > >> > > > On Mon, Nov 16, 2009 at 3:33 PM, Uwe Schindler < >> uschindler@pangaea.de >> > > > > wrote: >> > > > >> > > > Did 1.6 change the unicode version? Robert? >> > > > >> > > > ----- >> > > > UWE SCHINDLER >> > > > Webserver/Middleware Development >> > > > PANGAEA - Publishing Network for Geoscientific and Environmental >> > > Data >> > > > MARUM - University of Bremen >> > > > Room 2500, Leobener Str., D-28359 Bremen >> > > > Tel.: +49 421 218 65595 >> > > > Fax: +49 421 218 65505 >> > > > http://www.pangaea.de/ >> > > > E-mail : uschindler@pangaea.de >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: Mark Miller [mailto:markrmiller@gmail.com >> > > > ] >> > > > > Sent: Monday, November 16, 2009 9:30 PM >> > > > > To: java-dev@lucene.apache.org > > dev@lucene.apache.org> >> > > > > Subject: Re: Why release 3.0? >> > > > > >> > > > > And what happens when someone regenerates it with 1.6 without >> > > > knowing? >> > > > > >> > > > > Uwe Schindler wrote: >> > > > > > I check this by generating the file with 1.4 and 1.5. The >> 1.4 >> > > > version >> > > > > will >> > > > > > not change anymore, so we just leave the java file no jflex >> > > > anymore. The >> > > > > old >> > > > > > one is used for Lucene until 2.9, if you use >> > > > matchVersion=LUCENE_30, the >> > > > > new >> > > > > > one is used, which can also be regenerated. >> > > > > > >> > > > > > ----- >> > > > > > Uwe Schindler >> > > > > > H.-H.-Meier-Allee 63, D-28213 Bremen >> > > > > > http://www.thetaphi.de >> > > > > > eMail: uwe@thetaphi.de >> > > > > > >> > > > > > >> > > > > >> -----Original Message----- >> > > > > >> From: Mark Miller [mailto:markrmiller@gmail.com >> > > > ] >> > > > > >> Sent: Monday, November 16, 2009 9:21 PM >> > > > > >> To: java-dev@lucene.apache.org >> > > > >> > > > > >> Subject: Re: Why release 3.0? >> > > > > >> >> > > > > >> Good point - and that likely means the current warning is >> not >> > > > working - >> > > > > >> what can we do to improve it? >> > > > > >> >> > > > > >> Perhaps a new text file called jflexregen or something, and >> > it >> > > > > >> specifically says you must use java 1.5? >> > > > > >> >> > > > > >> Uwe Schindler wrote: >> > > > > >> >> > > > > >>> I think the regenerated code in Standard is since years no >> > > > longer >> > > > > >>> generated with 1.4 J Most developers use 1.5 or even 1.6. >> So >> > > it >> > > > > >>> already changed incompatible. >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> ----- >> > > > > >>> Uwe Schindler >> > > > > >>> H.-H.-Meier-Allee 63, D-28213 Bremen >> > > > > >>> http://www.thetaphi.de >> > > > > >>> eMail: uwe@thetaphi.de >> > > > > >>> >> > > > > >>> >> > > > >> ------------------------------------------------------------------ >> > -- >> > > -- >> > > > > -- >> > > > > >>> >> > > > > >>> *From:* Robert Muir [mailto:rcmuir@gmail.com >> > > > ] >> > > > > >>> *Sent:* Monday, November 16, 2009 8:52 PM >> > > > > >>> *To:* java-dev@lucene.apache.org >> > > > >> > > > > >>> *Subject:* Re: Why release 3.0? >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> Uwe, thats probably a good solution I think. just as long >> as >> > > we >> > > > > >>> document somewhere, >> > > > > >>> I think there is some warning verbage in StandardTokenizer >> > > > already >> > > > > >>> about this. >> > > > > >>> >> > > > > >>> NOTE: if you change StandardTokenizerImpl.jflex and need >> to >> > > > regenerate >> > > > > >>> the tokenizer, remember to use JRE 1.4 to run jflex >> > > > (before >> > > > > >>> Lucene 3.0). This grammar now uses constructs (eg >> > > > :digit:, >> > > > > >>> :letter:) whose meaning can vary according to the >> JRE >> > > > used to >> > > > > >>> run jflex. See >> > > > > >>> https://issues.apache.org/jira/browse/LUCENE-1126for >> > > > details. >> > > > > >>> >> > > > > >>> On Mon, Nov 16, 2009 at 2:50 PM, Uwe Schindler >> > > > >> > > > > >>> >> wrote: >> > > > > >>> >> > > > > >>> But it is a general warning that should be placed in the >> > > > Wiki: If you >> > > > > >>> upgrade from Java 1.4 to Java 5, think about reindexing. >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> It has definitely nothing to do with 3.0, because uses >> could >> > > > have >> > > > > >>> changed (and most of them have) before. >> > > > > >>> >> > > > > >>> ----- >> > > > > >>> Uwe Schindler >> > > > > >>> H.-H.-Meier-Allee 63, D-28213 Bremen >> > > > > >>> http://www.thetaphi.de >> > > > > >>> eMail: uwe@thetaphi.de >> > > > > >> > > > > >>> >> > > > > >>> >> > > > >> ------------------------------------------------------------------ >> > -- >> > > -- >> > > > > -- >> > > > > >>> >> > > > > >>> *From:* Robert Muir [mailto:rcmuir@gmail.com >> > > > >> > > > > >] >> > > > > >>> *Sent:* Monday, November 16, 2009 8:45 PM >> > > > > >>> >> > > > > >>> >> > > > > >>> *To:* java-dev@lucene.apache.org >> > > > >> > > > > > > > > >> > > > > >>> *Subject:* Re: Why release 3.0? >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> right, my point is its true its nothing to do with Lucene >> at >> > > > all, >> > > > > >>> >> > > > > >> really. >> > > > > >> >> > > > > >>> but the reality is we should clarify this to users I >> think. >> > > > > >>> >> > > > > >>> Its especially complex in the current StandardTokenizer, >> > > > which uses a >> > > > > >>> mix of hardcoded ranges and properties, can you tell me if >> > > > you should >> > > > > >>> reindex for given language X? >> > > > > >>> I wouldn't want to answer that question right now. >> > > > > >>> >> > > > > >>> On Mon, Nov 16, 2009 at 2:42 PM, Uwe Schindler >> > > > >> > > > > >>> >> wrote: >> > > > > >>> >> > > > > >>> We tried out: Character.getType() for these two chars: >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> Java 5: >> > > > > >>> '\u00AD' = 16 >> > > > > >>> '\u06DD' = 16 >> > > > > >>> >> > > > > >>> Java 1.4: >> > > > > >>> '\u00AD' = 20 >> > > > > >>> '\u06DD' = 7 >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> The first is the soft hyphen. >> > > > > >>> >> > > > > >>> ----- >> > > > > >>> Uwe Schindler >> > > > > >>> H.-H.-Meier-Allee 63, D-28213 Bremen >> > > > > >>> http://www.thetaphi.de >> > > > > >>> eMail: uwe@thetaphi.de >> > > > > >> > > > > >>> >> > > > > >>> >> > > > >> ------------------------------------------------------------------ >> > -- >> > > -- >> > > > > -- >> > > > > >>> >> > > > > >>> *From:* Robert Muir [mailto:rcmuir@gmail.com >> > > > >> > > > > >] >> > > > > >>> *Sent:* Monday, November 16, 2009 8:37 PM >> > > > > >>> >> > > > > >>> >> > > > > >>> *To:* java-dev@lucene.apache.org >> > > > >> > > > > > > > > >> > > > > >>> *Subject:* Re: Why release 3.0? >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> right, its nothing to do with lucene, instead due to >> > > > property changes, >> > > > > >>> etc. >> > > > > >>> >> > > > > >>> i just think we should inform users on java 1.4/2.9 that >> if >> > > they >> > > > > >>> upgrade to java 1.5/3.0, they should reindex. >> > > > > >>> >> > > > > >>> the reason i say this about properties, is there are some >> > > > that change >> > > > > >>> that will affect tokenizers, i give two examples, a hyphen >> > > that >> > > > > >>> changes from punctuation to format (might affect >> > > > > >>> >> > > > > >> SolrWordDelimiterFilter), >> > > > > >> >> > > > > >>> and arabic ayah which changes from NSM to format, which >> > > > surely affects >> > > > > >>> ArabicLetterTokenizer. >> > > > > >>> >> > > > > >>> On Mon, Nov 16, 2009 at 2:33 PM, Steven A Rowe >> > > > >> > > > > >>> >> wrote: >> > > > > >>> >> > > > > >>> Hi Robert, >> > > > > >>> >> > > > > >>> I agree that the Unicode version supported by the JVM, as >> > > > you say, >> > > > > >>> really has nothing to do with Lucene. >> > > > > >>> >> > > > > >>> The disruption here is users' upgrading from Java 1.4 to >> > > > 1.5+, not >> > > > > >>> when they upgrade Lucene. I'd guess with few exceptions >> > > > that most >> > > > > >>> people have been using Lucene with 1.5+ for a couple of >> > > > years now, >> > > > > >>> >> > > > > >> though. >> > > > > >> >> > > > > >>> But even the upgrade from Java 1.4 to 1.5+ will have (had) >> > > > zero impact >> > > > > >>> on most Lucene users, assuming that most use Latin-1 >> > > > exclusively; >> > > > > >>> although I haven't looked, I'd be surprised if Latin-1 >> > > > characters >> > > > > >>> changed much, if at all, from Unicode 3.0 to 4.0. >> > > > > >>> >> > > > > >>> It would be useful, I think, to include (a pointer to?) a >> > > > description >> > > > > >>> of the details of the Unicode 3.0->4.0 differences in the >> > > > Lucene 3.0 >> > > > > >>> release notes, since the minimum required Java version, >> and >> > > > so also >> > > > > >>> the supported Unicode version, changes then. >> > > > > >>> >> > > > > >>> Steve >> > > > > >>> >> > > > > >>> >> > > > > >>> On 11/16/2009 at 2:15 PM, Robert Muir wrote: >> > > > > >>> >> > > > > >>>> the problem is that the properties have changed for >> various >> > > > > >>>> >> > > > > >> characters, >> > > > > >> >> > > > > >>>> and new characters were added. >> > > > > >>>> >> > > > > >>>> it really has nothing to do with lucene, but the idea you >> > > > can go from >> > > > > >>>> jdk 1.4/lucene 2.9 to jdk 1.5/lucene3.0 without >> reindexing >> > > > is not >> > > > > >>>> >> > > > > >> true. >> > > > > >> >> > > > > >>>> On Mon, Nov 16, 2009 at 2:12 PM, Uwe Schindler >> > > > >> > > > > >>>> >> > > > > >>> >> wrote: >> > > > > >>> >> > > > > >>>> But an UTF-8 stream from Java 4 can still be read >> > > > with Java 5, >> > > > > >>>> what is the problem? Java 5 extended Unicode support, but >> > > > an index >> > > > > >>>> created with older versions can still be read. UTF-8 is >> > > > standardized. >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> ----- >> > > > > >>>> Uwe Schindler >> > > > > >>>> H.-H.-Meier-Allee 63, D-28213 Bremen >> > > > > >>>> http://www.thetaphi.de >> > > > > >>>> eMail: uwe@thetaphi.de >> > > > > >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> ________________________________ >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> From: Robert Muir [mailto:rcmuir@gmail.com >> > > > >> > > > > >>>> >> > > > > >>> >] >> > > > > >>> >> > > > > >>>> Sent: Monday, November 16, 2009 8:09 PM >> > > > > >>>> >> > > > > >>>> To: java-dev@lucene.apache.org >> > > > > > >> > > > > >>>> >> > > > > >> dev@lucene.apache.org > >> > > > > >> >> > > > > >>>> Subject: Re: Why release 3.0? >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> uwe, on topic please read my comment on >> LUCENE-1689, >> > > > because >> > > > > >>>> unicode version was bumped in jdk 1.5, i believe this >> index >> > > > backwards >> > > > > >>>> compatibility is only theoretical >> > > > > >>>> >> > > > > >>>> On Mon, Nov 16, 2009 at 2:05 PM, Uwe Schindler >> > > > >> > > > > >>>> >> > > > > >>> >> wrote: >> > > > > >>> >> > > > > >>>> 2.9 has *not* the same format as 3.0, an index >> > > > created with 3.0 >> > > > > >>>> cannot be read with 2.9. This is because compressed field >> > > > support was >> > > > > >>>> removed and therefore the version number of the stored >> > > > fields file >> > > > > was >> > > > > >>>> upgraded. But indexes from 2.9 can be read with 3.0 and >> > > > support may >> > > > > >>>> >> > > > > >> get >> > > > > >> >> > > > > >>>> removed in 4.0. 3.0 Indexes can be read until version >> 4.9. >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> Uwe >> > > > > >>>> >> > > > > >>>> ----- >> > > > > >>>> Uwe Schindler >> > > > > >>>> H.-H.-Meier-Allee 63, D-28213 Bremen >> > > > > >>>> http://www.thetaphi.de >> > > > > >>>> eMail: uwe@thetaphi.de >> > > > > >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> ________________________________ >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> From: Jake Mannix [mailto:jake.mannix@gmail.com >> > > > >> > > > > >>>> >> > > > > >>> > > >] >> > > > > >>> >> > > > > >>>> Sent: Monday, November 16, 2009 7:15 PM >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> To: java-dev@lucene.apache.org >> > > > > > >> > > > > >>>> >> > > > > >> dev@lucene.apache.org > >> > > > > >> >> > > > > >>>> Subject: Re: Why release 3.0? >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> Don't users need to upgrade to 3.0 because 3.1 >> won't >> > be >> > > > > >>>> necessarily able to read your >> > > > > >>>> 2.4 index file formats? I suppose if you've >> already >> > > > upgraded >> > > > > to >> > > > > >>>> 2.9, then all is well because >> > > > > >>>> 2.9 is the same format as 3.0, but we can't assume >> > > > all users >> > > > > >>>> upgraded from 2.4 to 2.9. >> > > > > >>>> >> > > > > >>>> If you've done that already, then 3.0 might not be >> > > > necessary, >> > > > > >>>> but if you're on 2.4 right now, >> > > > > >>>> you will be in for a bad surprise if you try to >> > > > upgrade to 3.1. >> > > > > >>>> >> > > > > >>>> -jake >> > > > > >>>> >> > > > > >>>> On Mon, Nov 16, 2009 at 10:10 AM, Erick Erickson >> > > > > >>>> > > >> > > > > >>> >> > > > wrote: >> > > > > >>>> >> > > > > >>>> One of my "specialties" is asking obvious questions >> > > > just to see >> > > > > >>>> if everyone's assumptions are aligned. So with the >> > > > discussion about >> > > > > >>>> branching 3.0 I have to ask "Is there going to be any 3.0 >> > > > release >> > > > > >>>> intended for *production*?". And if not, would we save a >> > lot >> > > of >> > > > > >>>> work by just not worrying about retrofitting fixes to a >> 3.0 >> > > > branch >> > > > > >>>> and carrying on with 3.1 as the first *supported* 3.x >> > > release? >> > > > > >>>> >> > > > > >>>> Since 3.0 is "upgrade-to-java5 and remove >> > > > deprecations", I'm >> > > > > not >> > > > > >>>> sure *as a user* I see a good reason to upgrade to 3.0. >> > > > Getting a >> > > > > >>>> "beta/snapshot" release to get a head start on cleaning >> up >> > > > my code >> > > > > >>>> does seem worthwhile, if I have the spare time. And >> having >> > > > a base >> > > > > >>>> 3.0 version that's not changing all over the place would >> be >> > > > useful >> > > > > >>>> for that. >> > > > > >>>> >> > > > > >>>> That said, I'm also not terribly comfortable with a >> > > > "release" >> > > > > >>>> that's out there and unsupported. >> > > > > >>>> >> > > > > >>>> Apologies if this has already been discussed, but I >> > > don't >> > > > > >>>> remember it. Although my memory isn't what it used to be >> > (but >> > > > > >>>> some would claim it never was)... >> > > > > >>>> >> > > > > >>>> Erick >> > > > > >>>> >> > > > > >>> >> > > > > >>> >> > > > > >>> -- >> > > > > >>> Robert Muir >> > > > > >>> rcmuir@gmail.com >> > > > > >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> -- >> > > > > >>> Robert Muir >> > > > > >>> rcmuir@gmail.com >> > > > > >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> -- >> > > > > >>> Robert Muir >> > > > > >>> rcmuir@gmail.com >> > > > > >> > > > > >>> >> > > > > >>> >> > > > > >> -- >> > > > > >> - Mark >> > > > > >> >> > > > > >> http://www.lucidimagination.com >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > >> ------------------------------------------------------------------ >> > -- >> > > - >> > > > > >> To unsubscribe, e-mail: >> > > > java-dev-unsubscribe@lucene.apache.org >> > > > >> > > > > >> For additional commands, e-mail: >> > > > java-dev-help@lucene.apache.org >> > > > >> > > > > >> >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > >> ------------------------------------------------------------------ >> > -- >> > > - >> > > > > > To unsubscribe, e-mail: >> java-dev-unsubscribe@lucene.apache.org >> > > > >> > > > > > For additional commands, e-mail: >> > > > java-dev-help@lucene.apache.org >> > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > - Mark >> > > > > >> > > > > http://www.lucidimagination.com >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> ------------------------------------------------------------------ >> > -- >> > > - >> > > > > To unsubscribe, e-mail: >> java-dev-unsubscribe@lucene.apache.org >> > > > >> > > > > For additional commands, e-mail: >> java-dev-help@lucene.apache.org >> > > > >> > > > >> > > > >> > > > >> > > > >> ------------------------------------------------------------------ >> > -- >> > > - >> > > > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> > > > >> > > > For additional commands, e-mail: >> java-dev-help@lucene.apache.org >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Robert Muir >> > > > rcmuir@gmail.com >> > > >> > > >> > > -- >> > > - Mark >> > > >> > > http://www.lucidimagination.com >> > > >> > > >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> > > For additional commands, e-mail: java-dev-help@lucene.apache.org >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> > For additional commands, e-mail: java-dev-help@lucene.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> For additional commands, e-mail: java-dev-help@lucene.apache.org >> >> > > > -- > Robert Muir > rcmuir@gmail.com > > > -- Robert Muir rcmuir@gmail.com --0016e64ce5b6addc7b047885966a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DM, in this case I'm not referring to surrogates, etc, but instead the = idea that properties for an existing character can change (the soft hyphen = and arabic ayah were two examples), also new characters are introduced.

these will affect what analysis components (ex. tokenizers) do, because= they like to use categories such as .isWhiteSpace, .isLetter, things like = that.

this means these components have different behavior, because t= hey are data-driven, even though we didnt change any code.

On Mon, Nov 16, 2009 at 6:37 PM, DM Smith <dmsmith555@gmai= l.com> wrote:
I'm not sure that anyone is force= d to go to Java 5. I think it is more that some will be stuck on Java 1.4. = My guess is that other than those that are on a very old version of MacOSX = (i.e. 10.3 aka Panther, Oct 2003-Apr 2005) everyone else is using Java 5 or= Java 6 already.

Is core lucene really affected by the change? Or is it = only contrib? I mean, if we couldn't create an index using core with su= rrogate pairs and other Unicode 4.0 stuff (though I'm not clear on the = changes), how can it change reading/searching the index?

-- DM

On Nov 16, 2009, at 4:36 PM, R= obert Muir wrote:

this fixes the standar= dTokenizer (thanks!!), but thats different, because its not dependent on th= e end users JVM.

i think we still need a warning to users, Mark opened an issue about it= , because other tokenizers are dependent on the end users JVM, and we are f= orcing them to upgrade to 1.5

On Mon, Nov 16, 2009 at 4:33 PM, Uwe Schindl= er <uwe@thetaphi.de> wrote:
I opened https://issues.apache.org/jira/browse/LUCENE-2074

It fixes the problem, the patch uses a different impl depending on
matchVersion.

If I commit it now, I would regenerate the rc1 artifacts and release the tomorrow to java-user. Currently the ones on people.apache.org are only
"known" to java-dev users.

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.d= e
eMail: uwe@thetaphi.de=


> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Monday, November 16, 2009 9:59 PM
> To: ja= va-dev@lucene.apache.org
> Subject: RE: Why release 3.0?
>
> OK, I checked. The JFLEX file in tunk was 1.4 generated. I regenerated=
> with
> 1.5 and it was different (completely!). I saved the old version and > renamed
> to StandardTokenizerImplJava14 extends StandardTokenizerImpl
>
> By this the impl is exchanged depending on version. The 1.4 version ca= n no
> longer be regenerated because it has no .jflex file and should really<= br> > never
> be regenerated.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.theta= phi.de
> eMail: uwe@thetap= hi.de
>
> > -----Original Message-----
> > From: Mark Miller [mailto:markrmiller@gmail.com]
> > Sent: Monday, November 16, 2009 9:45 PM
> > To: java-dev@lucene.apache.org
> > Subject: Re: Why release 3.0?
> >
> > I still reccomend we add a file then HowToRegenJflex.txt or somet= hing -
> > that specifically says to use 1.5 or 1.6. I don't changing th= e current
> > notice/warning is visible enough to ensure someone doesn't br= eak this.
> >
> > Robert Muir wrote:
> > > no. its still 4.0, but i hear 1.7 will be 5.1 or 5.2
> > >
> > > the only way to truly control this, would be to use somethin= g like ICU
> > > to control the unicode version being used (and actually be f= aster, and
> > > support higher version).
> > > see http://site.icu-project.org/home/why-use-icu4j
> > >
> > > the issue is that lucene does not have 3rd party library dep= endencies,
> > > on the other hand, i think tika and/or nutch already incorpo= rate icu
> > > for charset detection.
> > >
> > > i won't argue for this really, i know nobody wants it, b= ut you can see
> > > how the situation of not being able to control unicode seman= tics is
> > > really difficult for a search engine.
> > >
> > > On Mon, Nov 16, 2009 at 3:33 PM, Uwe Schindler <uschindler@pangaea.de
> > > <mailto:uschindler@pangaea.de>> wrote:
> > >
> > > =C2=A0 =C2=A0 Did 1.6 change the unicode version? Robert? > > >
> > > =C2=A0 =C2=A0 -----
> > > =C2=A0 =C2=A0 UWE SCHINDLER
> > > =C2=A0 =C2=A0 Webserver/Middleware Development
> > > =C2=A0 =C2=A0 PANGAEA - Publishing Network for Geoscientific= and Environmental
> > Data
> > > =C2=A0 =C2=A0 MARUM - University of Bremen
> > > =C2=A0 =C2=A0 Room 2500, Leobener Str., D-28359 Bremen
> > > =C2=A0 =C2=A0 Tel.: +49 421 218 65595
> > > =C2=A0 =C2=A0 Fax: =C2=A0+49 421 218 65505
> > > =C2=A0 =C2=A0 http://www.pangaea.de/
> > > =C2=A0 =C2=A0 E-mail <http://www.pangaea.de/%0AE-mail>: uschindler@pangaea.de
> > > =C2=A0 =C2=A0 <mailto:uschindler@pangaea.de>
> > >
> > > =C2=A0 =C2=A0 > -----Original Message-----
> > > =C2=A0 =C2=A0 > From: Mark Miller [mailto:markrmiller@gmail.com
> > > =C2=A0 =C2=A0 <mailto:markrmiller@gmail.com>]
> > > =C2=A0 =C2=A0 > Sent: Monday, November 16, 2009 9:30 PM > > > =C2=A0 =C2=A0 > To: java-dev@lucene.apache.org <mailto:java-
> dev@lucene.= apache.org>
> > > =C2=A0 =C2=A0 > Subject: Re: Why release 3.0?
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 > And what happens when someone regenerates= it with 1.6 without
> > > =C2=A0 =C2=A0 knowing?
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 > Uwe Schindler wrote:
> > > =C2=A0 =C2=A0 > > I check this by generating the file = with 1.4 and 1.5. The 1.4
> > > =C2=A0 =C2=A0 version
> > > =C2=A0 =C2=A0 > will
> > > =C2=A0 =C2=A0 > > not change anymore, so we just leave= the java file no jflex
> > > =C2=A0 =C2=A0 anymore. The
> > > =C2=A0 =C2=A0 > old
> > > =C2=A0 =C2=A0 > > one is used for Lucene until 2.9, if= you use
> > > =C2=A0 =C2=A0 matchVersion=3DLUCENE_30, the
> > > =C2=A0 =C2=A0 > new
> > > =C2=A0 =C2=A0 > > one is used, which can also be regen= erated.
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 > > -----
> > > =C2=A0 =C2=A0 > > Uwe Schindler
> > > =C2=A0 =C2=A0 > > H.-H.-Meier-Allee 63, D-28213 Bremen=
> > > =C2=A0 =C2=A0 > > http://www.thetaphi.de
> > > =C2=A0 =C2=A0 > > eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 > >> -----Original Message-----
> > > =C2=A0 =C2=A0 > >> From: Mark Miller [mailto:markrmiller@gmail.com<= /a>
> > > =C2=A0 =C2=A0 <mailto:markrmiller@gmail.com>]
> > > =C2=A0 =C2=A0 > >> Sent: Monday, November 16, 2009 = 9:21 PM
> > > =C2=A0 =C2=A0 > >> To: java-dev@lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org>
> > > =C2=A0 =C2=A0 > >> Subject: Re: Why release 3.0? > > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >> Good point - and that likely mea= ns the current warning is not
> > > =C2=A0 =C2=A0 working -
> > > =C2=A0 =C2=A0 > >> what can we do to improve it? > > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >> Perhaps a new text file called j= flexregen or something, and
> it
> > > =C2=A0 =C2=A0 > >> specifically says you must use j= ava 1.5?
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >> Uwe Schindler wrote:
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>> I think the regenerated code= in Standard is since years no
> > > =C2=A0 =C2=A0 longer
> > > =C2=A0 =C2=A0 > >>> generated with 1.4 J Most de= velopers use 1.5 or even 1.6. So
> > it
> > > =C2=A0 =C2=A0 > >>> already changed incompatible= .
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> -----
> > > =C2=A0 =C2=A0 > >>> Uwe Schindler
> > > =C2=A0 =C2=A0 > >>> H.-H.-Meier-Allee 63, D-2821= 3 Bremen
> > > =C2=A0 =C2=A0 > >>> http://www.thetaphi.de
> > > =C2=A0 =C2=A0 > >>> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 ----------------------------------------------= --------------------
> --
> > --
> > > =C2=A0 =C2=A0 > --
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> *From:* Robert Muir [mailto:= rcmuir@gmail.com<= br> > > > =C2=A0 =C2=A0 <mailto:rcmuir@gmail.com>]
> > > =C2=A0 =C2=A0 > >>> *Sent:* Monday, November 16,= 2009 8:52 PM
> > > =C2=A0 =C2=A0 > >>> *To:* java-dev@lucene.apache.org > > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org>
> > > =C2=A0 =C2=A0 > >>> *Subject:* Re: Why release 3= .0?
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> Uwe, thats probably a good s= olution I think. just as long as
> > we
> > > =C2=A0 =C2=A0 > >>> document somewhere,
> > > =C2=A0 =C2=A0 > >>> I think there is some warnin= g verbage in StandardTokenizer
> > > =C2=A0 =C2=A0 already
> > > =C2=A0 =C2=A0 > >>> about this.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> NOTE: if you change Standard= TokenizerImpl.jflex and need to
> > > =C2=A0 =C2=A0 regenerate
> > > =C2=A0 =C2=A0 > >>> =C2=A0 =C2=A0 =C2=A0 the tok= enizer, remember to use JRE 1.4 to run jflex
> > > =C2=A0 =C2=A0 (before
> > > =C2=A0 =C2=A0 > >>> =C2=A0 =C2=A0 =C2=A0 Lucene = 3.0). =C2=A0This grammar now uses constructs (eg
> > > =C2=A0 =C2=A0 :digit:,
> > > =C2=A0 =C2=A0 > >>> =C2=A0 =C2=A0 =C2=A0 :letter= :) whose meaning can vary according to the JRE
> > > =C2=A0 =C2=A0 used to
> > > =C2=A0 =C2=A0 > >>> =C2=A0 =C2=A0 =C2=A0 run jfl= ex. =C2=A0See
> > > =C2=A0 =C2=A0 > >>> =C2=A0 =C2=A0 =C2=A0 ht= tps://issues.apache.org/jira/browse/LUCENE-1126 for
> > > =C2=A0 =C2=A0 details.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> On Mon, Nov 16, 2009 at 2:50= PM, Uwe Schindler
> > > =C2=A0 =C2=A0 <uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 > >>> <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>&g= t; wrote:
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> But it is a general warning = that should be placed in the
> > > =C2=A0 =C2=A0 Wiki: If you
> > > =C2=A0 =C2=A0 > >>> upgrade from Java 1.4 to Jav= a 5, think about reindexing.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> It has definitely nothing to= do with 3.0, because uses could
> > > =C2=A0 =C2=A0 have
> > > =C2=A0 =C2=A0 > >>> changed (and most of them ha= ve) before.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> -----
> > > =C2=A0 =C2=A0 > >>> Uwe Schindler
> > > =C2=A0 =C2=A0 > >>> H.-H.-Meier-Allee 63, D-2821= 3 Bremen
> > > =C2=A0 =C2=A0 > >>> http://www.thetaphi.de
> > > =C2=A0 =C2=A0 > >>> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 ----------------------------------------------= --------------------
> --
> > --
> > > =C2=A0 =C2=A0 > --
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> *From:* Robert Muir [mailto:= rcmuir@gmail.com<= br> > > > =C2=A0 =C2=A0 <mailto:rcmuir@gmail.com>
> > > =C2=A0 =C2=A0 > <mailto:rcmuir@gmail.com <mailto:rcmuir@gmail.com>>]
> > > =C2=A0 =C2=A0 > >>> *Sent:* Monday, November 16,= 2009 8:45 PM
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> *To:* java-dev@lucene.apache.org > > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org>
> > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org>>
> > > =C2=A0 =C2=A0 > >>> *Subject:* Re: Why release 3= .0?
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> right, my point is its true = its nothing to do with Lucene at
> > > =C2=A0 =C2=A0 all,
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >> really.
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>> but the reality is we should= clarify this to users I think.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> Its especially complex in th= e current StandardTokenizer,
> > > =C2=A0 =C2=A0 which uses a
> > > =C2=A0 =C2=A0 > >>> mix of hardcoded ranges and = properties, can you tell me if
> > > =C2=A0 =C2=A0 you should
> > > =C2=A0 =C2=A0 > >>> reindex for given language X= ?
> > > =C2=A0 =C2=A0 > >>> I wouldn't want to answe= r that question right now.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> On Mon, Nov 16, 2009 at 2:42= PM, Uwe Schindler
> > > =C2=A0 =C2=A0 <uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 > >>> <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>&g= t; wrote:
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> We tried out: Character.getT= ype() for these two chars:
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> Java 5:
> > > =C2=A0 =C2=A0 > >>> '\u00AD' =3D 16
> > > =C2=A0 =C2=A0 > >>> '\u06DD' =3D 16
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> Java 1.4:
> > > =C2=A0 =C2=A0 > >>> '\u00AD' =3D 20
> > > =C2=A0 =C2=A0 > >>> '\u06DD' =3D 7
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> The first is the soft hyphen= .
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> -----
> > > =C2=A0 =C2=A0 > >>> Uwe Schindler
> > > =C2=A0 =C2=A0 > >>> H.-H.-Meier-Allee 63, D-2821= 3 Bremen
> > > =C2=A0 =C2=A0 > >>> http://www.thetaphi.de
> > > =C2=A0 =C2=A0 > >>> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 ----------------------------------------------= --------------------
> --
> > --
> > > =C2=A0 =C2=A0 > --
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> *From:* Robert Muir [mailto:= rcmuir@gmail.com<= br> > > > =C2=A0 =C2=A0 <mailto:rcmuir@gmail.com>
> > > =C2=A0 =C2=A0 > <mailto:rcmuir@gmail.com <mailto:rcmuir@gmail.com>>]
> > > =C2=A0 =C2=A0 > >>> *Sent:* Monday, November 16,= 2009 8:37 PM
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> *To:* java-dev@lucene.apache.org > > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org>
> > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org>>
> > > =C2=A0 =C2=A0 > >>> *Subject:* Re: Why release 3= .0?
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> right, its nothing to do wit= h lucene, instead due to
> > > =C2=A0 =C2=A0 property changes,
> > > =C2=A0 =C2=A0 > >>> etc.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> i just think we should infor= m users on java 1.4/2.9 that if
> > they
> > > =C2=A0 =C2=A0 > >>> upgrade to java 1.5/3.0, the= y should reindex.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> the reason i say this about = properties, is there are some
> > > =C2=A0 =C2=A0 that change
> > > =C2=A0 =C2=A0 > >>> that will affect tokenizers,= i give two examples, a hyphen
> > that
> > > =C2=A0 =C2=A0 > >>> changes from punctuation to = format (might affect
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >> SolrWordDelimiterFilter),
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>> and arabic ayah which change= s from NSM to format, which
> > > =C2=A0 =C2=A0 surely affects
> > > =C2=A0 =C2=A0 > >>> ArabicLetterTokenizer.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> On Mon, Nov 16, 2009 at 2:33= PM, Steven A Rowe
> > > =C2=A0 =C2=A0 <sarowe@syr.edu <mailto:sarowe@syr.edu>
> > > =C2=A0 =C2=A0 > >>> <mailto:sarowe@syr.edu <mailto:sarowe@syr.edu>>> wr= ote:
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> Hi Robert,
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> I agree that the Unicode ver= sion supported by the JVM, as
> > > =C2=A0 =C2=A0 you say,
> > > =C2=A0 =C2=A0 > >>> really has nothing to do wit= h Lucene.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> The disruption here is users= ' upgrading from Java 1.4 to
> > > =C2=A0 =C2=A0 1.5+, not
> > > =C2=A0 =C2=A0 > >>> when they upgrade Lucene. = =C2=A0I'd guess with few exceptions
> > > =C2=A0 =C2=A0 that most
> > > =C2=A0 =C2=A0 > >>> people have been using Lucen= e with 1.5+ for a couple of
> > > =C2=A0 =C2=A0 years now,
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >> though.
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>> But even the upgrade from Ja= va 1.4 to 1.5+ will have (had)
> > > =C2=A0 =C2=A0 zero impact
> > > =C2=A0 =C2=A0 > >>> on most Lucene users, assumi= ng that most use Latin-1
> > > =C2=A0 =C2=A0 exclusively;
> > > =C2=A0 =C2=A0 > >>> although I haven't looke= d, I'd be surprised if Latin-1
> > > =C2=A0 =C2=A0 characters
> > > =C2=A0 =C2=A0 > >>> changed much, if at all, fro= m Unicode 3.0 to 4.0.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> It would be useful, I think,= to include (a pointer to?) a
> > > =C2=A0 =C2=A0 description
> > > =C2=A0 =C2=A0 > >>> of the details of the Unicod= e 3.0->4.0 differences in the
> > > =C2=A0 =C2=A0 Lucene 3.0
> > > =C2=A0 =C2=A0 > >>> release notes, since the min= imum required Java version, and
> > > =C2=A0 =C2=A0 so also
> > > =C2=A0 =C2=A0 > >>> the supported Unicode versio= n, changes then.
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> Steve
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> On 11/16/2009 at 2:15 PM, Ro= bert Muir wrote:
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>> the problem is that the = properties have changed for various
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >> characters,
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>>> and new characters were = added.
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> it really has nothing to= do with lucene, but the idea you
> > > =C2=A0 =C2=A0 can go from
> > > =C2=A0 =C2=A0 > >>>> jdk 1.4/lucene 2.9 to jd= k 1.5/lucene3.0 without reindexing
> > > =C2=A0 =C2=A0 is not
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >> true.
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>>> On Mon, Nov 16, 2009 at = 2:12 PM, Uwe Schindler
> > > =C2=A0 =C2=A0 <uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>> <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>&g= t; wrote:
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 But= an UTF-8 stream from Java 4 can still be read
> > > =C2=A0 =C2=A0 with Java 5,
> > > =C2=A0 =C2=A0 > >>>> what is the problem? Jav= a 5 extended Unicode support, but
> > > =C2=A0 =C2=A0 an index
> > > =C2=A0 =C2=A0 > >>>> created with older versi= ons can still be read. UTF-8 is
> > > =C2=A0 =C2=A0 standardized.
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 ---= --
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Uwe= Schindler
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 H.-= H.-Meier-Allee 63, D-28213 Bremen
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 http://www.thetaphi.de
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 eMa= il: uwe@thetaphi.de <mailto:uwe@theta= phi.de>
> > > =C2=A0 =C2=A0 <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> ________________________= ________
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Fro= m: Robert Muir [mailto:rcmuir@gmail.com
> > > =C2=A0 =C2=A0 <mailto:rcmuir@gmail.com>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>> <mailto:rcmuir@gmail.com <mailto:rcmuir@gmail.com>>= ;]
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Sen= t: Monday, November 16, 2009 8:09 PM
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 To:= java-dev@l= ucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org> <mailto:= java- <mailto:java->
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >> dev@lucene.apache.org <mailto:dev@lucene.apache.org&g= t;>
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Sub= ject: Re: Why release 3.0?
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 uwe= , on topic please read my comment on LUCENE-1689,
> > > =C2=A0 =C2=A0 because
> > > =C2=A0 =C2=A0 > >>>> unicode version was bump= ed in jdk 1.5, i believe this index
> > > =C2=A0 =C2=A0 backwards
> > > =C2=A0 =C2=A0 > >>>> compatibility is only th= eoretical
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 On = Mon, Nov 16, 2009 at 2:05 PM, Uwe Schindler
> > > =C2=A0 =C2=A0 <uwe@thetaphi.de <mailto:uwe@thetaphi.de>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>> <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>&g= t; wrote:
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 2.9= has *not* the same format as 3.0, an index
> > > =C2=A0 =C2=A0 created with 3.0
> > > =C2=A0 =C2=A0 > >>>> cannot be read with 2.9.= This is because compressed field
> > > =C2=A0 =C2=A0 support was
> > > =C2=A0 =C2=A0 > >>>> removed and therefore th= e version number of the stored
> > > =C2=A0 =C2=A0 fields file
> > > =C2=A0 =C2=A0 > was
> > > =C2=A0 =C2=A0 > >>>> upgraded. But indexes fr= om 2.9 can be read with 3.0 and
> > > =C2=A0 =C2=A0 support may
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >> get
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>>> removed in 4.0. 3.0 Inde= xes can be read until version 4.9.
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Uwe=
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 ---= --
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Uwe= Schindler
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 H.-= H.-Meier-Allee 63, D-28213 Bremen
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 http://www.thetaphi.de
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 eMa= il: uwe@thetaphi.de <mailto:uwe@theta= phi.de>
> > > =C2=A0 =C2=A0 <mailto:uwe@thetaphi.de <mailto:uwe@thetaphi.de>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> ________________________= ________
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Fro= m: Jake Mannix [mailto:jake.mannix@gmail.com
> > > =C2=A0 =C2=A0 <mailto:jake.mannix@gmail.com>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>> <mailto:jake.mannix@gmail.com
> <mailto:= jake.mannix@gmail.com>>]
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Sen= t: Monday, November 16, 2009 7:15 PM
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 To:= java-dev@l= ucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev@lucene.apache.org> <mailto:= java- <mailto:java->
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >> dev@lucene.apache.org <mailto:dev@lucene.apache.org&g= t;>
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Sub= ject: Re: Why release 3.0?
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Don= 't users need to upgrade to 3.0 because 3.1 won't
> be
> > > =C2=A0 =C2=A0 > >>>> necessarily able to read= your
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 2.4= index file formats? =C2=A0I suppose if you've already
> > > =C2=A0 =C2=A0 upgraded
> > > =C2=A0 =C2=A0 > to
> > > =C2=A0 =C2=A0 > >>>> 2.9, then all is well be= cause
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 2.9= is the same format as 3.0, but we can't assume
> > > =C2=A0 =C2=A0 all users
> > > =C2=A0 =C2=A0 > >>>> upgraded from 2.4 to 2.9= .
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 If = you've done that already, then 3.0 might not be
> > > =C2=A0 =C2=A0 necessary,
> > > =C2=A0 =C2=A0 > >>>> but if you're on 2.4= right now,
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 you= will be in for a bad surprise if you try to
> > > =C2=A0 =C2=A0 upgrade to 3.1.
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 -jake
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 On = Mon, Nov 16, 2009 at 10:10 AM, Erick Erickson
> > > =C2=A0 =C2=A0 > >>>> <erickerickson@gmail.com <ma= ilto:erickeric= kson@gmail.com>
> > > =C2=A0 =C2=A0 <mailto:erickerickson@gmail.com <mailto:erickerickson@gmail.com<= /a>>>>
> > > =C2=A0 =C2=A0 wrote:
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 One= of my "specialties" is asking obvious questions
> > > =C2=A0 =C2=A0 just to see
> > > =C2=A0 =C2=A0 > >>>> if everyone's assump= tions are aligned. So with the
> > > =C2=A0 =C2=A0 discussion about
> > > =C2=A0 =C2=A0 > >>>> branching 3.0 I have to = ask "Is there going to be any 3.0
> > > =C2=A0 =C2=A0 release
> > > =C2=A0 =C2=A0 > >>>> intended for *production= *?". And if not, would we save a
> lot
> > of
> > > =C2=A0 =C2=A0 > >>>> work by just not worryin= g about retrofitting fixes to a 3.0
> > > =C2=A0 =C2=A0 branch
> > > =C2=A0 =C2=A0 > >>>> and carrying on with 3.1= as the first *supported* 3.x
> > release?
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Sin= ce 3.0 is "upgrade-to-java5 and remove
> > > =C2=A0 =C2=A0 deprecations", I'm
> > > =C2=A0 =C2=A0 > not
> > > =C2=A0 =C2=A0 > >>>> sure *as a user* I see a= good reason to upgrade to 3.0.
> > > =C2=A0 =C2=A0 Getting a
> > > =C2=A0 =C2=A0 > >>>> "beta/snapshot"= ; release to get a head start on cleaning up
> > > =C2=A0 =C2=A0 my code
> > > =C2=A0 =C2=A0 > >>>> does seem worthwhile, if= I have the spare time. And having
> > > =C2=A0 =C2=A0 a base
> > > =C2=A0 =C2=A0 > >>>> 3.0 version that's n= ot changing all over the place would be
> > > =C2=A0 =C2=A0 useful
> > > =C2=A0 =C2=A0 > >>>> for that.
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Tha= t said, I'm also not terribly comfortable with a
> > > =C2=A0 =C2=A0 "release"
> > > =C2=A0 =C2=A0 > >>>> that's out there and= unsupported.
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Apo= logies if this has already been discussed, but I
> > don't
> > > =C2=A0 =C2=A0 > >>>> remember it. Although my= memory isn't what it used to be
> (but
> > > =C2=A0 =C2=A0 > >>>> some would claim it neve= r was<G>)...
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>> =C2=A0 =C2=A0 =C2=A0 Eri= ck
> > > =C2=A0 =C2=A0 > >>>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> --
> > > =C2=A0 =C2=A0 > >>> Robert Muir
> > > =C2=A0 =C2=A0 > >>> rcmuir@gmail.com <mailto:rcmuir@gmail.com>
> > > =C2=A0 =C2=A0 <mailto:rcmuir@gmail.com <mailto:rcmuir@gmail.com>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> --
> > > =C2=A0 =C2=A0 > >>> Robert Muir
> > > =C2=A0 =C2=A0 > >>> rcmuir@gmail.com <mailto:rcmuir@gmail.com>
> > > =C2=A0 =C2=A0 <mailto:rcmuir@gmail.com <mailto:rcmuir@gmail.com>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>> --
> > > =C2=A0 =C2=A0 > >>> Robert Muir
> > > =C2=A0 =C2=A0 > >>> rcmuir@gmail.com <mailto:rcmuir@gmail.com>
> > > =C2=A0 =C2=A0 <mailto:rcmuir@gmail.com <mailto:rcmuir@gmail.com>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >>>
> > > =C2=A0 =C2=A0 > >> --
> > > =C2=A0 =C2=A0 > >> - Mark
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >> http://www.lucidimagination.com
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 ----------------------------------------------= --------------------
> --
> > -
> > > =C2=A0 =C2=A0 > >> To unsubscribe, e-mail:
> > > =C2=A0 =C2=A0 java-dev-unsubscribe@lucene.apache.org > > > =C2=A0 =C2=A0 <mailto:java-dev-unsubscribe@lucene.apache= .org>
> > > =C2=A0 =C2=A0 > >> For additional commands, e-mail:=
> > > =C2=A0 =C2=A0 java-dev-help@lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev-help@lucene.apache.org> > > > =C2=A0 =C2=A0 > >>
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 ----------------------------------------------= --------------------
> --
> > -
> > > =C2=A0 =C2=A0 > > To unsubscribe, e-mail: java-dev-un= subscribe@lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev-unsubscribe@lucene.apache= .org>
> > > =C2=A0 =C2=A0 > > For additional commands, e-mail:
> > > =C2=A0 =C2=A0 java-dev-help@lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev-help@lucene.apache.org> > > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 > >
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 > --
> > > =C2=A0 =C2=A0 > - Mark
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 > http://www.lucidimagination.com
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 >
> > > =C2=A0 =C2=A0 ----------------------------------------------= --------------------
> --
> > -
> > > =C2=A0 =C2=A0 > To unsubscribe, e-mail: java-dev-unsubsc= ribe@lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev-unsubscribe@lucene.apache= .org>
> > > =C2=A0 =C2=A0 > For additional commands, e-mail: java-dev-help= @lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev-help@lucene.apache.org> > > >
> > >
> > >
> > > =C2=A0 =C2=A0 ----------------------------------------------= --------------------
> --
> > -
> > > =C2=A0 =C2=A0 To unsubscribe, e-mail: java-dev-unsubscribe@= lucene.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev-unsubscribe@lucene.apache= .org>
> > > =C2=A0 =C2=A0 For additional commands, e-mail: java-dev-help@lucen= e.apache.org
> > > =C2=A0 =C2=A0 <mailto:java-dev-help@lucene.apache.org> > > >
> > >
> > >
> > >
> > > --
> > > Robert Muir
> > > rcmuir= @gmail.com <mailto:rcmuir@gmail.com>
> >
> >
> > --
> > - Mark
> >
> > ht= tp://www.lucidimagination.com
> >
> >
> >
> >
> > -----------------------------------------------------------------= ----
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org >
>
>
> ---------------------------------------------------------------------<= br> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-dev-help@lucene.apache.org



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




--
Robert Muir=
rcmuir@gmail.com<= /a>




--
Robert Muir
rcmuir@gmail.com
--0016e64ce5b6addc7b047885966a--