|
Michael McCandless
2009-10-26, 16:18
Uwe Schindler
2009-10-26, 16:43
Yonik Seeley
2009-10-26, 16:47
Michael McCandless
2009-10-26, 18:43
Grant Ingersoll
2009-10-26, 19:48
Andi Vajda
2009-10-26, 20:52
Uwe Schindler
2009-10-26, 21:24
Ralph Seward
2009-10-27, 14:43
Robert Muir
2009-10-28, 12:04
Uwe Schindler
2009-10-29, 10:13
Michael McCandless
2009-10-29, 23:27
Uwe Schindler
2009-10-31, 00:17
Michael Busch
2009-10-31, 02:05
Yonik Seeley
2009-10-31, 17:59
Grant Ingersoll
2009-11-01, 21:41
Grant Ingersoll
2009-11-02, 15:30
Uwe Schindler
2009-11-21, 14:39
Uwe Schindler
2009-11-22, 15:07
Uwe Schindler
2009-11-22, 21:23
Uwe Schindler
2009-11-22, 21:41
yangfeng
2009-11-23, 03:56
Uwe Schindler
2009-11-24, 07:26
Michael McCandless
2009-11-24, 10:01
Uwe Schindler
2009-11-24, 10:09
Andi Vajda
2009-11-25, 04:10
Helmut Jarausch
2009-11-25, 09:32
Uwe Schindler
2009-11-25, 09:46
Michael McCandless
2009-11-25, 09:47
Uwe Schindler
2009-11-25, 14:51
Grant Ingersoll
2009-11-25, 14:53
Uwe Schindler
2009-11-25, 15:09
Andi Vajda
2009-11-25, 16:10
Helmut Jarausch
2009-11-26, 10:15
|
-
[VOTE] Release Apache Lucene Java 2.9.1Michael McCandless 2009-10-26, 16:18
OK, I've built release artifacts from svn rev 829846 (on the 2.9
branch), here: http://people.apache.org/~mikemccand/staging-area/lucene2.9.1/ Changes are here: http://people.apache.org/~mikemccand/staging-area/lucene2.9.1changes/ Please vote to officially release these artifacts as Apache Lucene Java 2.9.1. Mike
-
RE: [VOTE] Release Apache Lucene Java 2.9.1Uwe Schindler 2009-10-26, 16:43
Looks good. One thing:
In Mark's artifacts, he changed the common-build.xml to not have -dev in the version before the release. You can see this in SVN. I am fine with having -dev in the source artefact, because if someone compiles his own bin from the artefact, it should have -dev in it, because it's not an official build. Any comments about this?: I found something in https://issues.apache.org/jira/browse/LUCENE-1973 that may need un-deprecation. Can you and Mark Miller also look into it? I find the method is very useful to prevent users from creating TopFieldDocCollector manually, what produced lots of confusion about the parameters of the static ctor (have to ask the weight for it..., hard to explain for someone, who only wants scores for sorted results). Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Michael McCandless [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 26, 2009 5:18 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [VOTE] Release Apache Lucene Java 2.9.1 > > OK, I've built release artifacts from svn rev 829846 (on the 2.9 > branch), here: > > http://people.apache.org/~mikemccand/staging-area/lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
-
Re: [VOTE] Release Apache Lucene Java 2.9.1Yonik Seeley 2009-10-26, 16:47
On Mon, Oct 26, 2009 at 12:43 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> Looks good. One thing: > > In Mark's artifacts, he changed the common-build.xml to not have -dev in the > version before the release. You can see this in SVN. I am fine with having > -dev in the source artefact, because if someone compiles his own bin from > the artefact, it should have -dev in it, because it's not an official build. Right, having the "-dev" when someone tries to build it themselves is the way we should keep it. -Yonik http://www.lucidimagination.com
-
[VOTE] Release Apache Lucene Java 2.9.1, take 2Michael McCandless 2009-10-26, 18:43
OK, I've built new release artifacts (incorporating Uwes feedback)
from svn rev 829889 (on the 2.9 branch), here: http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1/ Changes are here: http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1changes/ Please vote to officially release these artifacts as Apache Lucene Java 2.9.1. Mike
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 2Grant Ingersoll 2009-10-26, 19:48
+1
On Oct 26, 2009, at 2:43 PM, Michael McCandless wrote: > OK, I've built new release artifacts (incorporating Uwes feedback) > from svn rev 829889 (on the 2.9 branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. > > Mike
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 2Andi Vajda 2009-10-26, 20:52
On Mon, 26 Oct 2009, Michael McCandless wrote: > OK, I've built new release artifacts (incorporating Uwes feedback) > from svn rev 829889 (on the 2.9 branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. I'm not sure my vote counts because I didn't actually verify the artifacts as uploaded. Instead I built PyLucene 2.9.1 with the Lucene 2.9 branch HEAD and verified that PyLucene 2.9.1 built and that all tests passed. +1, still Andi..
-
RE: [VOTE] Release Apache Lucene Java 2.9.1, take 2Uwe Schindler 2009-10-26, 21:24
> OK, I've built new release artifacts (incorporating Uwes feedback) > from svn rev 829889 (on the 2.9 branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging- > area/rc2_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. +1 I tested the lucene-core.jar artifact also with my current 2.9.0 project and worked without recompilation. CheckIndex after optimizing shows 2.9.1 as version. Also JavaDocs look better than 2.9.0 and the changes for 3.0 (undeprecations) are implemented. I verified that the nasty BooleanQuery bug is fine now and therefore will set the update now to production :-) Everything else looks like Mark's 2.9.0 release. Nice work! Uwe
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 2Ralph Seward 2009-10-27, 14:43
+1
On Mon, Oct 26, 2009 at 5:24 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote: > > > OK, I've built new release artifacts (incorporating Uwes feedback) > > from svn rev 829889 (on the 2.9 branch), here: > > > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1/<http://people.apache.org/%7Emikemccand/staging-area/rc2_lucene2.9.1/> > > > > Changes are here: > > > > http://people.apache.org/~mikemccand/staging-<http://people.apache.org/%7Emikemccand/staging-> > > area/rc2_lucene2.9.1changes/ > > > > Please vote to officially release these artifacts as Apache Lucene > > Java 2.9.1. > > +1 > > I tested the lucene-core.jar artifact also with my current 2.9.0 project > and > worked without recompilation. CheckIndex after optimizing shows 2.9.1 as > version. Also JavaDocs look better than 2.9.0 and the changes for 3.0 > (undeprecations) are implemented. > > I verified that the nasty BooleanQuery bug is fine now and therefore will > set the update now to production :-) > > Everything else looks like Mark's 2.9.0 release. Nice work! > > Uwe > >
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 2Robert Muir 2009-10-28, 12:04
+1
On Mon, Oct 26, 2009 at 2:43 PM, Michael McCandless < [EMAIL PROTECTED]> wrote: > OK, I've built new release artifacts (incorporating Uwes feedback) > from svn rev 829889 (on the 2.9 branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1/<http://people.apache.org/%7Emikemccand/staging-area/rc2_lucene2.9.1/> > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/rc2_lucene2.9.1changes/<http://people.apache.org/%7Emikemccand/staging-area/rc2_lucene2.9.1changes/> > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Robert Muir [EMAIL PROTECTED]
-
RE: [VOTE] Release Apache Lucene Java 2.9.1, take 2Uwe Schindler 2009-10-29, 10:13
Robert found another bug in 2.9. I resolved one yesterday and reopened
LUCENE-2002. So I changed my mind: -1 :( ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Robert Muir [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 28, 2009 1:05 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [VOTE] Release Apache Lucene Java 2.9.1, take 2 > > +1 > > On Mon, Oct 26, 2009 at 2:43 PM, Michael McCandless < > [EMAIL PROTECTED]> wrote: > > > OK, I've built new release artifacts (incorporating Uwes feedback) > > from svn rev 829889 (on the 2.9 branch), here: > > > > http://people.apache.org/~mikemccand/staging- > area/rc2_lucene2.9.1/<http://people.apache.org/%7Emikemccand/staging- > area/rc2_lucene2.9.1/> > > > > Changes are here: > > > > http://people.apache.org/~mikemccand/staging- > area/rc2_lucene2.9.1changes/<http://people.apache.org/%7Emikemccand/stagin > g-area/rc2_lucene2.9.1changes/> > > > > Please vote to officially release these artifacts as Apache Lucene > > Java 2.9.1. > > > > Mike > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Robert Muir > [EMAIL PROTECTED]
-
[VOTE] Release Apache Lucene Java 2.9.1, take 3Michael McCandless 2009-10-29, 23:27
OK, let's try this again!
I've built new release artifacts from svn rev 831145 (on the 2.9 branch), here: http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/ Changes are here: http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1changes/ Please vote to officially release these artifacts as Apache Lucene Java 2.9.1. Mike
-
RE: [VOTE] Release Apache Lucene Java 2.9.1, take 3Uwe Schindler 2009-10-31, 00:17
+1 Looks good, no problems detected!
Greetings from Oakland, just arrived. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Michael McCandless [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 29, 2009 4:27 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [VOTE] Release Apache Lucene Java 2.9.1, take 3 > > OK, let's try this again! > > I've built new release artifacts from svn rev 831145 (on the 2.9 > branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging- > area/rc3_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. > > Mike
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 3Michael Busch 2009-10-31, 02:05
+1
Michael On 10/29/09 4:27 PM, Michael McCandless wrote: > OK, let's try this again! > > I've built new release artifacts from svn rev 831145 (on the 2.9 > branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > >
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 3Yonik Seeley 2009-10-31, 17:59
On Thu, Oct 29, 2009 at 7:27 PM, Michael McCandless
<[EMAIL PROTECTED]> wrote: > OK, let's try this again! > > I've built new release artifacts from svn rev 831145 (on the 2.9 > branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. +1 -Yonik http://www.lucidimagination.com
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 3Grant Ingersoll 2009-11-01, 21:41
Where are the MD5 hashes of the top level artifacts?
On Oct 29, 2009, at 7:27 PM, Michael McCandless wrote: > OK, let's try this again! > > I've built new release artifacts from svn rev 831145 (on the 2.9 > branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. > > Mike
-
Re: [VOTE] Release Apache Lucene Java 2.9.1, take 3Grant Ingersoll 2009-11-02, 15:30
+1
On Oct 29, 2009, at 4:27 PM, Michael McCandless wrote: > OK, let's try this again! > > I've built new release artifacts from svn rev 831145 (on the 2.9 > branch), here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1/ > > Changes are here: > > http://people.apache.org/~mikemccand/staging-area/rc3_lucene2.9.1changes/ > > Please vote to officially release these artifacts as Apache Lucene > Java 2.9.1. > > Mike
-
[VOTE] Release Apache Lucene Java 3.0.0Uwe Schindler 2009-11-21, 14:39
Hi,
I have built the artifacts for the final release of "Apache Lucene Java 3.0.0", targeted for release on 2009-11-25. The artifacts are here: http://people.apache.org/~uschindler/staging-area/lucene-3.0.0/ You find the changes in the corresponding sub folder. The SVN revision is 882890, here the manifest with build system info: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) Specification-Title: Lucene Search Engine Specification-Version: 3.0.0 Specification-Vendor: The Apache Software Foundation Implementation-Title: org.apache.lucene Implementation-Version: 3.0.0 882890 - 2009-11-21 15:07:59 Implementation-Vendor: The Apache Software Foundation X-Compile-Source-JDK: 1.5 X-Compile-Target-JDK: 1.5 Please vote to officially release these artifacts as "Apache Lucene Java 3.0.0". We need at least 3 binding (PMC) votes. Thanks everyone for all their hard work on this! Here is the proposed release note, please edit, if needed: -------------------------------------------------------------------------- Hello Lucene users, On behalf of the Lucene dev community (a growing community far larger than just the committers) I would like to announce the release of Lucene Java 3.0: The new version is mostly a cleanup release without any new features. All deprecations targeted to be removed in version 3.0 were removed. If you are upgrading from version 2.9.1 of Lucene, you have to fix all deprecation warnings in your code base to be able to recompile against this version. This is the first Lucene release with Java 5 as a minimum requirement. The API was cleaned up to make use of Java 5's generics, varargs, enums, and autoboxing. New users of Lucene are advised to use this version for new developments, because it has a clean, type safe new API. Upgrading users can now remove unnecessary casts and add generics to their code, too. If you have not upgraded your installation to Java 5, please read the file JRE_VERSION_MIGRATION.txt (please note that this is not related to Lucene 3.0, it will also happen with any previous release when you upgrade your Java environment). Lucene 3.0 has some changes regarding compressed fields: 2.9 already deprecated compressed fields; support for them was removed now. Lucene 3.0 is still able to read indexes with compressed fields, but as soon as merges occur or the index is optimized, all compressed fields are decompressed and converted to Field.Store.YES. Because of this, indexes with compressed fields can suddenly get larger. While we generally try and maintain full backwards compatibility between major versions, Lucene 3.0 has some minor breaks, mostly related to deprecation removal, pointed out in the 'Changes in backwards compatibility policy' section of CHANGES.txt. Notable are: - IndexReader.open(Directory) now opens in read-only mode per default (this method was deprecated because of that in 2.9). The same occurs to IndexSearcher. - Already started in 2.9, core TokenStreams are now made final to enforce the decorator pattern. - If you interrupt an IndexWriter merge thread, IndexWriter now throws an unchecked ThreadInterruptedException that extends RuntimeException and clears the interrupt status. -------------------------------------------------------------------------- Thanks, Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED]
-
[VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-22, 15:07
Hi,
I have built the artifacts for the final release of "Apache Lucene Java 3.0.0" a second time, because of a bug in the TokenStream API (found by Shai Erera, who wanted to make "bad" things with addAttribute, breaking its behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to prevent stack overflow, LUCENE-2087). They are targeted for release on 2009-11-25. The artifacts are here: http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ You find the changes in the corresponding sub folder. The SVN revision is 883080, here the manifest with build system info: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) Specification-Title: Lucene Search Engine Specification-Version: 3.0.0 Specification-Vendor: The Apache Software Foundation Implementation-Title: org.apache.lucene Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 Implementation-Vendor: The Apache Software Foundation X-Compile-Source-JDK: 1.5 X-Compile-Target-JDK: 1.5 Please vote to officially release these artifacts as "Apache Lucene Java 3.0.0". We need at least 3 binding (PMC) votes. Thanks everyone for all their hard work on this and I am very sorry for requesting a vote again, but that's life! Thanks Shai for the pointer to the bug! Here is the proposed release note, please edit, if needed: -------------------------------------------------------------------------- Hello Lucene users, On behalf of the Lucene dev community (a growing community far larger than just the committers) I would like to announce the release of Lucene Java 3.0: The new version is mostly a cleanup release without any new features. All deprecations targeted to be removed in version 3.0 were removed. If you are upgrading from version 2.9.1 of Lucene, you have to fix all deprecation warnings in your code base to be able to recompile against this version. This is the first Lucene release with Java 5 as a minimum requirement. The API was cleaned up to make use of Java 5's generics, varargs, enums, and autoboxing. New users of Lucene are advised to use this version for new developments, because it has a clean, type safe new API. Upgrading users can now remove unnecessary casts and add generics to their code, too. If you have not upgraded your installation to Java 5, please read the file JRE_VERSION_MIGRATION.txt (please note that this is not related to Lucene 3.0, it will also happen with any previous release when you upgrade your Java environment). Lucene 3.0 has some changes regarding compressed fields: 2.9 already deprecated compressed fields; support for them was removed now. Lucene 3.0 is still able to read indexes with compressed fields, but as soon as merges occur or the index is optimized, all compressed fields are decompressed and converted to Field.Store.YES. Because of this, indexes with compressed fields can suddenly get larger. While we generally try and maintain full backwards compatibility between major versions, Lucene 3.0 has some minor breaks, mostly related to deprecation removal, pointed out in the 'Changes in backwards compatibility policy' section of CHANGES.txt. Notable are: - IndexReader.open(Directory) now opens in read-only mode per default (this method was deprecated because of that in 2.9). The same occurs to IndexSearcher. - Already started in 2.9, core TokenStreams are now made final to enforce the decorator pattern. - If you interrupt an IndexWriter merge thread, IndexWriter now throws an unchecked ThreadInterruptedException that extends RuntimeException and clears the interrupt status. -------------------------------------------------------------------------- Thanks, Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED]
-
RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-22, 21:23
Hi,
As a non-counting vote: +1 to release these artifacts as Lucene 3.0 I tested lucene-core.3.0.0.jar with my updated application, no problems occurred. QueryParser search works, fieldcache/sorting works, numeric range works. Reopen also works correct, no leftover open files. MMPaDirectory on 64 bit Java 1.5.0_22 on Solaris. Merging old indexes with compressed fields created newer, but larger segments (as expected). I also reindexed my indexes, filesize was identical to the one after merge/optimize with compress expansion, so the indexes seems to be identical. I only had to change some parts of my code and remove lots of unneeded casts (thanks to generics). :-) ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Uwe Schindler [mailto:[EMAIL PROTECTED]] > Sent: Sunday, November 22, 2009 4:07 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > > Hi, > > I have built the artifacts for the final release of "Apache Lucene Java > 3.0.0" a second time, because of a bug in the TokenStream API (found by > Shai > Erera, who wanted to make "bad" things with addAttribute, breaking its > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to > prevent > stack overflow, LUCENE-2087). They are targeted for release on 2009-11-25. > > The artifacts are here: > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > You find the changes in the corresponding sub folder. The SVN revision is > 883080, here the manifest with build system info: > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.7.0 > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > Specification-Title: Lucene Search Engine > Specification-Version: 3.0.0 > Specification-Vendor: The Apache Software Foundation > Implementation-Title: org.apache.lucene > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > Implementation-Vendor: The Apache Software Foundation > X-Compile-Source-JDK: 1.5 > X-Compile-Target-JDK: 1.5 > > Please vote to officially release these artifacts as "Apache Lucene Java > 3.0.0". > > We need at least 3 binding (PMC) votes. > > Thanks everyone for all their hard work on this and I am very sorry for > requesting a vote again, but that's life! Thanks Shai for the pointer to > the > bug! > > > > > Here is the proposed release note, please edit, if needed: > -------------------------------------------------------------------------- > > Hello Lucene users, > > On behalf of the Lucene dev community (a growing community far larger than > just the committers) I would like to announce the release of Lucene Java > 3.0: > > The new version is mostly a cleanup release without any new features. All > deprecations targeted to be removed in version 3.0 were removed. If you > are > upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > warnings in your code base to be able to recompile against this version. > > This is the first Lucene release with Java 5 as a minimum requirement. The > API was cleaned up to make use of Java 5's generics, varargs, enums, and > autoboxing. New users of Lucene are advised to use this version for new > developments, because it has a clean, type safe new API. Upgrading users > can > now remove unnecessary casts and add generics to their code, too. If you > have not upgraded your installation to Java 5, please read the file > JRE_VERSION_MIGRATION.txt (please note that this is not related to Lucene > 3.0, it will also happen with any previous release when you upgrade your > Java environment). > > Lucene 3.0 has some changes regarding compressed fields: 2.9 already > deprecated compressed fields; support for them was removed now. Lucene 3.0 > is still able to read indexes with compressed fields, but as soon as > merges > occur or the index is optimized, all compressed fields are decompressed > and > converted to Field.Store.YES. Because of this, indexes with compressed
-
RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-22, 21:41
> Hi,
> > As a non-counting vote: > > +1 to release these artifacts as Lucene 3.0 > > I tested lucene-core.3.0.0.jar with my updated application, no problems > occurred. QueryParser search works, fieldcache/sorting works, numeric > range > works. Reopen also works correct, no leftover open files. MMPaDirectory on > 64 bit Java 1.5.0_22 on Solaris. Merging old indexes with compressed > fields > created newer, but larger segments (as expected). > I also reindexed my indexes, filesize was identical to the one after > merge/optimize with compress expansion, so the indexes seems to be > identical. > > I only had to change some parts of my code and remove lots of unneeded > casts > (thanks to generics). :-) And I forgot: I was able to build and test the whole distribution from the source ZIP. JavaDocs of binary distrib were ok, too. So no change: +1 :-) Uwe > > -----Original Message----- > > From: Uwe Schindler [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, November 22, 2009 4:07 PM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > > > > Hi, > > > > I have built the artifacts for the final release of "Apache Lucene Java > > 3.0.0" a second time, because of a bug in the TokenStream API (found by > > Shai > > Erera, who wanted to make "bad" things with addAttribute, breaking its > > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to > > prevent > > stack overflow, LUCENE-2087). They are targeted for release on 2009-11- > 25. > > > > The artifacts are here: > > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > > > You find the changes in the corresponding sub folder. The SVN revision > is > > 883080, here the manifest with build system info: > > > > Manifest-Version: 1.0 > > Ant-Version: Apache Ant 1.7.0 > > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > > Specification-Title: Lucene Search Engine > > Specification-Version: 3.0.0 > > Specification-Vendor: The Apache Software Foundation > > Implementation-Title: org.apache.lucene > > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > > Implementation-Vendor: The Apache Software Foundation > > X-Compile-Source-JDK: 1.5 > > X-Compile-Target-JDK: 1.5 > > > > Please vote to officially release these artifacts as "Apache Lucene Java > > 3.0.0". > > > > We need at least 3 binding (PMC) votes. > > > > Thanks everyone for all their hard work on this and I am very sorry for > > requesting a vote again, but that's life! Thanks Shai for the pointer to > > the > > bug! > > > > > > > > > > Here is the proposed release note, please edit, if needed: > > ------------------------------------------------------------------------ > -- > > > > Hello Lucene users, > > > > On behalf of the Lucene dev community (a growing community far larger > than > > just the committers) I would like to announce the release of Lucene Java > > 3.0: > > > > The new version is mostly a cleanup release without any new features. > All > > deprecations targeted to be removed in version 3.0 were removed. If you > > are > > upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > > warnings in your code base to be able to recompile against this version. > > > > This is the first Lucene release with Java 5 as a minimum requirement. > The > > API was cleaned up to make use of Java 5's generics, varargs, enums, and > > autoboxing. New users of Lucene are advised to use this version for new > > developments, because it has a clean, type safe new API. Upgrading users > > can > > now remove unnecessary casts and add generics to their code, too. If you > > have not upgraded your installation to Java 5, please read the file > > JRE_VERSION_MIGRATION.txt (please note that this is not related to > Lucene > > 3.0, it will also happen with any previous release when you upgrade your > > Java environment). > > > > Lucene 3.0 has some changes regarding compressed fields: 2.9 already > > deprecated compressed fields; support for them was removed now. Lucene
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)yangfeng 2009-11-23, 03:56
+1
2009/11/23 Uwe Schindler <[EMAIL PROTECTED]> > > Hi, > > > > As a non-counting vote: > > > > +1 to release these artifacts as Lucene 3.0 > > > > I tested lucene-core.3.0.0.jar with my updated application, no problems > > occurred. QueryParser search works, fieldcache/sorting works, numeric > > range > > works. Reopen also works correct, no leftover open files. MMPaDirectory > on > > 64 bit Java 1.5.0_22 on Solaris. Merging old indexes with compressed > > fields > > created newer, but larger segments (as expected). > > I also reindexed my indexes, filesize was identical to the one after > > merge/optimize with compress expansion, so the indexes seems to be > > identical. > > > > I only had to change some parts of my code and remove lots of unneeded > > casts > > (thanks to generics). :-) > > And I forgot: > I was able to build and test the whole distribution from the source ZIP. > JavaDocs of binary distrib were ok, too. > > So no change: +1 :-) > > Uwe > > > > -----Original Message----- > > > From: Uwe Schindler [mailto:[EMAIL PROTECTED]] > > > Sent: Sunday, November 22, 2009 4:07 PM > > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > Subject: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > > > > > > Hi, > > > > > > I have built the artifacts for the final release of "Apache Lucene Java > > > 3.0.0" a second time, because of a bug in the TokenStream API (found by > > > Shai > > > Erera, who wanted to make "bad" things with addAttribute, breaking its > > > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to > > > prevent > > > stack overflow, LUCENE-2087). They are targeted for release on 2009-11- > > 25. > > > > > > The artifacts are here: > > > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > > > > > You find the changes in the corresponding sub folder. The SVN revision > > is > > > 883080, here the manifest with build system info: > > > > > > Manifest-Version: 1.0 > > > Ant-Version: Apache Ant 1.7.0 > > > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > > > Specification-Title: Lucene Search Engine > > > Specification-Version: 3.0.0 > > > Specification-Vendor: The Apache Software Foundation > > > Implementation-Title: org.apache.lucene > > > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > > > Implementation-Vendor: The Apache Software Foundation > > > X-Compile-Source-JDK: 1.5 > > > X-Compile-Target-JDK: 1.5 > > > > > > Please vote to officially release these artifacts as "Apache Lucene > Java > > > 3.0.0". > > > > > > We need at least 3 binding (PMC) votes. > > > > > > Thanks everyone for all their hard work on this and I am very sorry for > > > requesting a vote again, but that's life! Thanks Shai for the pointer > to > > > the > > > bug! > > > > > > > > > > > > > > > Here is the proposed release note, please edit, if needed: > > > > ------------------------------------------------------------------------ > > -- > > > > > > Hello Lucene users, > > > > > > On behalf of the Lucene dev community (a growing community far larger > > than > > > just the committers) I would like to announce the release of Lucene > Java > > > 3.0: > > > > > > The new version is mostly a cleanup release without any new features. > > All > > > deprecations targeted to be removed in version 3.0 were removed. If you > > > are > > > upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > > > warnings in your code base to be able to recompile against this > version. > > > > > > This is the first Lucene release with Java 5 as a minimum requirement. > > The > > > API was cleaned up to make use of Java 5's generics, varargs, enums, > and > > > autoboxing. New users of Lucene are advised to use this version for new > > > developments, because it has a clean, type safe new API. Upgrading > users > > > can > > > now remove unnecessary casts and add generics to their code, too. If > you > > > have not upgraded your installation to Java 5, please read the file > >
-
RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-24, 07:26
Hi all,
Hoss reported a bug about two fields missing in the equals/hashCode of BooleanQuery (which exists since 1.9, https://issues.apache.org/jira/browse/LUCENE-2092). Should I respin 3.0 because of this or just release it? Speak out load, if you want to respin (else vote)! We will apply the bugfix at least to 2.9.2 and 3.0.1 Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Uwe Schindler [mailto:[EMAIL PROTECTED]] > Sent: Sunday, November 22, 2009 4:07 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > > Hi, > > I have built the artifacts for the final release of "Apache Lucene Java > 3.0.0" a second time, because of a bug in the TokenStream API (found by > Shai > Erera, who wanted to make "bad" things with addAttribute, breaking its > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to > prevent > stack overflow, LUCENE-2087). They are targeted for release on 2009-11-25. > > The artifacts are here: > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > You find the changes in the corresponding sub folder. The SVN revision is > 883080, here the manifest with build system info: > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.7.0 > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > Specification-Title: Lucene Search Engine > Specification-Version: 3.0.0 > Specification-Vendor: The Apache Software Foundation > Implementation-Title: org.apache.lucene > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > Implementation-Vendor: The Apache Software Foundation > X-Compile-Source-JDK: 1.5 > X-Compile-Target-JDK: 1.5 > > Please vote to officially release these artifacts as "Apache Lucene Java > 3.0.0". > > We need at least 3 binding (PMC) votes. > > Thanks everyone for all their hard work on this and I am very sorry for > requesting a vote again, but that's life! Thanks Shai for the pointer to > the > bug! > > > > > Here is the proposed release note, please edit, if needed: > -------------------------------------------------------------------------- > > Hello Lucene users, > > On behalf of the Lucene dev community (a growing community far larger than > just the committers) I would like to announce the release of Lucene Java > 3.0: > > The new version is mostly a cleanup release without any new features. All > deprecations targeted to be removed in version 3.0 were removed. If you > are > upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > warnings in your code base to be able to recompile against this version. > > This is the first Lucene release with Java 5 as a minimum requirement. The > API was cleaned up to make use of Java 5's generics, varargs, enums, and > autoboxing. New users of Lucene are advised to use this version for new > developments, because it has a clean, type safe new API. Upgrading users > can > now remove unnecessary casts and add generics to their code, too. If you > have not upgraded your installation to Java 5, please read the file > JRE_VERSION_MIGRATION.txt (please note that this is not related to Lucene > 3.0, it will also happen with any previous release when you upgrade your > Java environment). > > Lucene 3.0 has some changes regarding compressed fields: 2.9 already > deprecated compressed fields; support for them was removed now. Lucene 3.0 > is still able to read indexes with compressed fields, but as soon as > merges > occur or the index is optimized, all compressed fields are decompressed > and > converted to Field.Store.YES. Because of this, indexes with compressed > fields can suddenly get larger. > > While we generally try and maintain full backwards compatibility between > major versions, Lucene 3.0 has some minor breaks, mostly related to > deprecation removal, pointed out in the 'Changes in backwards > compatibility > policy' section of CHANGES.txt. Notable are:
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Michael McCandless 2009-11-24, 10:01
As DM Smith said, since the bug is longstanding and we are only now
just hearing about it, it appears not to be that severe in practice. I guess users don't often mix coord enabled & disabled BQs, that are otherwise identical, in the same cache. So I think we ship 3.0.0 anyways? Mike On Tue, Nov 24, 2009 at 2:26 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote: > Hi all, > > Hoss reported a bug about two fields missing in the equals/hashCode of > BooleanQuery (which exists since 1.9, > https://issues.apache.org/jira/browse/LUCENE-2092). Should I respin 3.0 > because of this or just release it? Speak out load, if you want to respin > (else vote)! > > We will apply the bugfix at least to 2.9.2 and 3.0.1 > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [EMAIL PROTECTED] > >> -----Original Message----- >> From: Uwe Schindler [mailto:[EMAIL PROTECTED]] >> Sent: Sunday, November 22, 2009 4:07 PM >> To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >> Subject: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) >> >> Hi, >> >> I have built the artifacts for the final release of "Apache Lucene Java >> 3.0.0" a second time, because of a bug in the TokenStream API (found by >> Shai >> Erera, who wanted to make "bad" things with addAttribute, breaking its >> behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to >> prevent >> stack overflow, LUCENE-2087). They are targeted for release on 2009-11-25. >> >> The artifacts are here: >> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ >> >> You find the changes in the corresponding sub folder. The SVN revision is >> 883080, here the manifest with build system info: >> >> Manifest-Version: 1.0 >> Ant-Version: Apache Ant 1.7.0 >> Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) >> Specification-Title: Lucene Search Engine >> Specification-Version: 3.0.0 >> Specification-Vendor: The Apache Software Foundation >> Implementation-Title: org.apache.lucene >> Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 >> Implementation-Vendor: The Apache Software Foundation >> X-Compile-Source-JDK: 1.5 >> X-Compile-Target-JDK: 1.5 >> >> Please vote to officially release these artifacts as "Apache Lucene Java >> 3.0.0". >> >> We need at least 3 binding (PMC) votes. >> >> Thanks everyone for all their hard work on this and I am very sorry for >> requesting a vote again, but that's life! Thanks Shai for the pointer to >> the >> bug! >> >> >> >> >> Here is the proposed release note, please edit, if needed: >> -------------------------------------------------------------------------- >> >> Hello Lucene users, >> >> On behalf of the Lucene dev community (a growing community far larger than >> just the committers) I would like to announce the release of Lucene Java >> 3.0: >> >> The new version is mostly a cleanup release without any new features. All >> deprecations targeted to be removed in version 3.0 were removed. If you >> are >> upgrading from version 2.9.1 of Lucene, you have to fix all deprecation >> warnings in your code base to be able to recompile against this version. >> >> This is the first Lucene release with Java 5 as a minimum requirement. The >> API was cleaned up to make use of Java 5's generics, varargs, enums, and >> autoboxing. New users of Lucene are advised to use this version for new >> developments, because it has a clean, type safe new API. Upgrading users >> can >> now remove unnecessary casts and add generics to their code, too. If you >> have not upgraded your installation to Java 5, please read the file >> JRE_VERSION_MIGRATION.txt (please note that this is not related to Lucene >> 3.0, it will also happen with any previous release when you upgrade your >> Java environment). >> >> Lucene 3.0 has some changes regarding compressed fields: 2.9 already >> deprecated compressed fields; support for them was removed now. Lucene 3.0 >> is still able to read indexes with compressed fields, but as soon as
-
RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-24, 10:09
> As DM Smith said, since the bug is longstanding and we are only now
> just hearing about it, it appears not to be that severe in practice. > I guess users don't often mix coord enabled & disabled BQs, that are > otherwise identical, in the same cache. DM Smith also wanted this in 2.9.2, which I think it's fine. The fix is so simple, we could simply merge it to 2.9 branch. And Erick Erickson also noted that this bug is longstanding. > So I think we ship 3.0.0 anyways? +1, I just wanted to ask. Now votes are required, I have zero counting ones until now. Uwe > On Tue, Nov 24, 2009 at 2:26 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > Hoss reported a bug about two fields missing in the equals/hashCode of > > BooleanQuery (which exists since 1.9, > > https://issues.apache.org/jira/browse/LUCENE-2092). Should I respin 3.0 > > because of this or just release it? Speak out load, if you want to > respin > > (else vote)! > > > > We will apply the bugfix at least to 2.9.2 and 3.0.1 > > > > Uwe > > > > ----- > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: [EMAIL PROTECTED] > > > >> -----Original Message----- > >> From: Uwe Schindler [mailto:[EMAIL PROTECTED]] > >> Sent: Sunday, November 22, 2009 4:07 PM > >> To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > >> Subject: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > >> > >> Hi, > >> > >> I have built the artifacts for the final release of "Apache Lucene Java > >> 3.0.0" a second time, because of a bug in the TokenStream API (found by > >> Shai > >> Erera, who wanted to make "bad" things with addAttribute, breaking its > >> behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to > >> prevent > >> stack overflow, LUCENE-2087). They are targeted for release on 2009-11- > 25. > >> > >> The artifacts are here: > >> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > >> > >> You find the changes in the corresponding sub folder. The SVN revision > is > >> 883080, here the manifest with build system info: > >> > >> Manifest-Version: 1.0 > >> Ant-Version: Apache Ant 1.7.0 > >> Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > >> Specification-Title: Lucene Search Engine > >> Specification-Version: 3.0.0 > >> Specification-Vendor: The Apache Software Foundation > >> Implementation-Title: org.apache.lucene > >> Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > >> Implementation-Vendor: The Apache Software Foundation > >> X-Compile-Source-JDK: 1.5 > >> X-Compile-Target-JDK: 1.5 > >> > >> Please vote to officially release these artifacts as "Apache Lucene > Java > >> 3.0.0". > >> > >> We need at least 3 binding (PMC) votes. > >> > >> Thanks everyone for all their hard work on this and I am very sorry for > >> requesting a vote again, but that's life! Thanks Shai for the pointer > to > >> the > >> bug! > >> > >> > >> > >> > >> Here is the proposed release note, please edit, if needed: > >> ----------------------------------------------------------------------- > --- > >> > >> Hello Lucene users, > >> > >> On behalf of the Lucene dev community (a growing community far larger > than > >> just the committers) I would like to announce the release of Lucene > Java > >> 3.0: > >> > >> The new version is mostly a cleanup release without any new features. > All > >> deprecations targeted to be removed in version 3.0 were removed. If you > >> are > >> upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > >> warnings in your code base to be able to recompile against this > version. > >> > >> This is the first Lucene release with Java 5 as a minimum requirement. > The > >> API was cleaned up to make use of Java 5's generics, varargs, enums, > and > >> autoboxing. New users of Lucene are advised to use this version for new > >> developments, because it has a clean, type safe new API. Upgrading > users > >> can > >> now remove unnecessary casts and add generics to their code, too. If
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Andi Vajda 2009-11-25, 04:10
On Sun, 22 Nov 2009, Uwe Schindler wrote: > I have built the artifacts for the final release of "Apache Lucene Java > 3.0.0" a second time, because of a bug in the TokenStream API (found by Shai > Erera, who wanted to make "bad" things with addAttribute, breaking its > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to prevent > stack overflow, LUCENE-2087). They are targeted for release on 2009-11-25. > > The artifacts are here: > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > You find the changes in the corresponding sub folder. The SVN revision is > 883080, here the manifest with build system info: > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.7.0 > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > Specification-Title: Lucene Search Engine > Specification-Version: 3.0.0 > Specification-Vendor: The Apache Software Foundation > Implementation-Title: org.apache.lucene > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > Implementation-Vendor: The Apache Software Foundation > X-Compile-Source-JDK: 1.5 > X-Compile-Target-JDK: 1.5 > > Please vote to officially release these artifacts as "Apache Lucene Java > 3.0.0". > > We need at least 3 binding (PMC) votes. > > Thanks everyone for all their hard work on this and I am very sorry for > requesting a vote again, but that's life! Thanks Shai for the pointer to the > bug! I built PyLucene trunk using Lucene Java source from the artifact's svn rev and all unit tests and ported "Lucene in Action" tests pass. +1 ! Andi..
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Helmut Jarausch 2009-11-25, 09:32
On 24 Nov, Andi Vajda wrote:
> I built PyLucene trunk using Lucene Java source from the artifact's svn rev > and all unit tests and ported "Lucene in Action" tests pass. > > +1 ! > > Andi.. Many thanks, Andi. Here (AMD64, python-2.6.4) a single test fails java development with ant: 0.502968132496 junit in action: 0.812919199467 0.812919199467: JUnit in Action 0.502968132496: Java Development with Ant /usr/bin/python samples/LuceneInAction/CompoundVersusMultiFileIndexTest.py F =====================================================================FAIL: testTiming (lia.indexing.CompoundVersusMultiFileIndexTest.CompoundVersusMultiFileIndexTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Work1/Obj/Python/pylucene-build/samples/LuceneInAction/lia/indexing/CompoundVersusMultiFileIndexTest.py", line 62, in testTiming self.assert_(cTiming > mTiming) AssertionError Hopefully, this isn't critical. What could be the reason? Thanks again, Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany
-
RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-25, 09:46
I would really not see this as a real test failure. The test assumes that a
compound file index is slower during indexing, which is normally so. But maybe the scheduler of your O/S did something strange at the time the test ran and made it take longer to index without compound file. Is it reproducible? In my opinion, the test is invalid, it just shows something that happens most of the time, but asserting it is wrong. I looked at the Java Version of the test: http://java.codefetch.com/example/in/LuceneInAction/src/lia/indexing/Compoun dVersusMultiFileIndexTest.java Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Helmut Jarausch [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 25, 2009 10:33 AM > To: [EMAIL PROTECTED] > Cc: Andi Vajda > Subject: Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > > On 24 Nov, Andi Vajda wrote: > > I built PyLucene trunk using Lucene Java source from the artifact's svn > rev > > and all unit tests and ported "Lucene in Action" tests pass. > > > > +1 ! > > > > Andi.. > > Many thanks, Andi. > > Here (AMD64, python-2.6.4) a single test fails > java development with ant: 0.502968132496 > junit in action: 0.812919199467 > 0.812919199467: JUnit in Action > 0.502968132496: Java Development with Ant > /usr/bin/python samples/LuceneInAction/CompoundVersusMultiFileIndexTest.py > F > =====================================================================> FAIL: testTiming > (lia.indexing.CompoundVersusMultiFileIndexTest.CompoundVersusMultiFileInde > xTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/Work1/Obj/Python/pylucene- > build/samples/LuceneInAction/lia/indexing/CompoundVersusMultiFileIndexTest > .py", line 62, in testTiming > self.assert_(cTiming > mTiming) > AssertionError > > > Hopefully, this isn't critical. > What could be the reason? > > Thanks again, > Helmut. > > -- > Helmut Jarausch > > Lehrstuhl fuer Numerische Mathematik > RWTH - Aachen University > D 52056 Aachen, Germany
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Michael McCandless 2009-11-25, 09:47
That failure can be ignored.
The test is old (was in the 1st rev of the book, but I've removed it in the 2nd edition) -- it's asserting that building a tiny index using compound file is faster than building one with multi file, which in general is true, but for a tiny index the difference can be in the noise. Mike On Wed, Nov 25, 2009 at 4:32 AM, Helmut Jarausch <[EMAIL PROTECTED]> wrote: > On 24 Nov, Andi Vajda wrote: >> I built PyLucene trunk using Lucene Java source from the artifact's svn rev >> and all unit tests and ported "Lucene in Action" tests pass. >> >> +1 ! >> >> Andi.. > > Many thanks, Andi. > > Here (AMD64, python-2.6.4) a single test fails > java development with ant: 0.502968132496 > junit in action: 0.812919199467 > 0.812919199467: JUnit in Action > 0.502968132496: Java Development with Ant > /usr/bin/python samples/LuceneInAction/CompoundVersusMultiFileIndexTest.py > F > =====================================================================> FAIL: testTiming (lia.indexing.CompoundVersusMultiFileIndexTest.CompoundVersusMultiFileIndexTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/Work1/Obj/Python/pylucene-build/samples/LuceneInAction/lia/indexing/CompoundVersusMultiFileIndexTest.py", line 62, in testTiming > self.assert_(cTiming > mTiming) > AssertionError > > > Hopefully, this isn't critical. > What could be the reason? > > Thanks again, > Helmut. > > -- > Helmut Jarausch > > Lehrstuhl fuer Numerische Mathematik > RWTH - Aachen University > D 52056 Aachen, Germany >
-
RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-25, 14:51
I need one more vote!? Does somebody have some +1 anywhere? :-)
Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Uwe Schindler [mailto:[EMAIL PROTECTED]] > Sent: Sunday, November 22, 2009 4:07 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > > Hi, > > I have built the artifacts for the final release of "Apache Lucene Java > 3.0.0" a second time, because of a bug in the TokenStream API (found by > Shai > Erera, who wanted to make "bad" things with addAttribute, breaking its > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to > prevent > stack overflow, LUCENE-2087). They are targeted for release on 2009-11-25. > > The artifacts are here: > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > You find the changes in the corresponding sub folder. The SVN revision is > 883080, here the manifest with build system info: > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.7.0 > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > Specification-Title: Lucene Search Engine > Specification-Version: 3.0.0 > Specification-Vendor: The Apache Software Foundation > Implementation-Title: org.apache.lucene > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > Implementation-Vendor: The Apache Software Foundation > X-Compile-Source-JDK: 1.5 > X-Compile-Target-JDK: 1.5 > > Please vote to officially release these artifacts as "Apache Lucene Java > 3.0.0". > > We need at least 3 binding (PMC) votes. > > Thanks everyone for all their hard work on this and I am very sorry for > requesting a vote again, but that's life! Thanks Shai for the pointer to > the > bug! > > > > > Here is the proposed release note, please edit, if needed: > -------------------------------------------------------------------------- > > Hello Lucene users, > > On behalf of the Lucene dev community (a growing community far larger than > just the committers) I would like to announce the release of Lucene Java > 3.0: > > The new version is mostly a cleanup release without any new features. All > deprecations targeted to be removed in version 3.0 were removed. If you > are > upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > warnings in your code base to be able to recompile against this version. > > This is the first Lucene release with Java 5 as a minimum requirement. The > API was cleaned up to make use of Java 5's generics, varargs, enums, and > autoboxing. New users of Lucene are advised to use this version for new > developments, because it has a clean, type safe new API. Upgrading users > can > now remove unnecessary casts and add generics to their code, too. If you > have not upgraded your installation to Java 5, please read the file > JRE_VERSION_MIGRATION.txt (please note that this is not related to Lucene > 3.0, it will also happen with any previous release when you upgrade your > Java environment). > > Lucene 3.0 has some changes regarding compressed fields: 2.9 already > deprecated compressed fields; support for them was removed now. Lucene 3.0 > is still able to read indexes with compressed fields, but as soon as > merges > occur or the index is optimized, all compressed fields are decompressed > and > converted to Field.Store.YES. Because of this, indexes with compressed > fields can suddenly get larger. > > While we generally try and maintain full backwards compatibility between > major versions, Lucene 3.0 has some minor breaks, mostly related to > deprecation removal, pointed out in the 'Changes in backwards > compatibility > policy' section of CHANGES.txt. Notable are: > > - IndexReader.open(Directory) now opens in read-only mode per default > (this > method was deprecated because of that in 2.9). The same occurs to > IndexSearcher. > > - Already started in 2.9, core TokenStreams are now made final to enforce
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Grant Ingersoll 2009-11-25, 14:53
+1. I downloaded the artifacts, tried the demo, verified signatures, MD5s, etc.
On Nov 22, 2009, at 10:07 AM, Uwe Schindler wrote: > Hi, > > I have built the artifacts for the final release of "Apache Lucene Java > 3.0.0" a second time, because of a bug in the TokenStream API (found by Shai > Erera, who wanted to make "bad" things with addAttribute, breaking its > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to prevent > stack overflow, LUCENE-2087). They are targeted for release on 2009-11-25. > > The artifacts are here: > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > You find the changes in the corresponding sub folder. The SVN revision is > 883080, here the manifest with build system info: > > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.7.0 > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > Specification-Title: Lucene Search Engine > Specification-Version: 3.0.0 > Specification-Vendor: The Apache Software Foundation > Implementation-Title: org.apache.lucene > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > Implementation-Vendor: The Apache Software Foundation > X-Compile-Source-JDK: 1.5 > X-Compile-Target-JDK: 1.5 > > Please vote to officially release these artifacts as "Apache Lucene Java > 3.0.0". > > We need at least 3 binding (PMC) votes. > > Thanks everyone for all their hard work on this and I am very sorry for > requesting a vote again, but that's life! Thanks Shai for the pointer to the > bug! > > > > > Here is the proposed release note, please edit, if needed: > -------------------------------------------------------------------------- > > Hello Lucene users, > > On behalf of the Lucene dev community (a growing community far larger than > just the committers) I would like to announce the release of Lucene Java > 3.0: > > The new version is mostly a cleanup release without any new features. All > deprecations targeted to be removed in version 3.0 were removed. If you are > upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > warnings in your code base to be able to recompile against this version. > > This is the first Lucene release with Java 5 as a minimum requirement. The > API was cleaned up to make use of Java 5's generics, varargs, enums, and > autoboxing. New users of Lucene are advised to use this version for new > developments, because it has a clean, type safe new API. Upgrading users can > now remove unnecessary casts and add generics to their code, too. If you > have not upgraded your installation to Java 5, please read the file > JRE_VERSION_MIGRATION.txt (please note that this is not related to Lucene > 3.0, it will also happen with any previous release when you upgrade your > Java environment). > > Lucene 3.0 has some changes regarding compressed fields: 2.9 already > deprecated compressed fields; support for them was removed now. Lucene 3.0 > is still able to read indexes with compressed fields, but as soon as merges > occur or the index is optimized, all compressed fields are decompressed and > converted to Field.Store.YES. Because of this, indexes with compressed > fields can suddenly get larger. > > While we generally try and maintain full backwards compatibility between > major versions, Lucene 3.0 has some minor breaks, mostly related to > deprecation removal, pointed out in the 'Changes in backwards compatibility > policy' section of CHANGES.txt. Notable are: > > - IndexReader.open(Directory) now opens in read-only mode per default (this > method was deprecated because of that in 2.9). The same occurs to > IndexSearcher. > > - Already started in 2.9, core TokenStreams are now made final to enforce > the decorator pattern. > > - If you interrupt an IndexWriter merge thread, IndexWriter now throws an > unchecked ThreadInterruptedException that extends RuntimeException and > clears the interrupt status. > > -------------------------------------------------------------------------- > >
-
RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Uwe Schindler 2009-11-25, 15:09
Thanks!
So I think I start to copy the artefacts to the apache/maven dist directories and update the websites tomorrow. I got the following binding votes for Lucene Java 3.0.0 artefacts: +1 Grant Ingersoll +1 Mike McCandless +1 Andi Vajda And the following non binding ones: +1 yangfeng +1 Simon Willnauer +1 Uwe Schindler Thanks, Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [EMAIL PROTECTED] > -----Original Message----- > From: Grant Ingersoll [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 25, 2009 3:54 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) > > +1. I downloaded the artifacts, tried the demo, verified signatures, > MD5s, etc. > > On Nov 22, 2009, at 10:07 AM, Uwe Schindler wrote: > > > Hi, > > > > I have built the artifacts for the final release of "Apache Lucene Java > > 3.0.0" a second time, because of a bug in the TokenStream API (found by > Shai > > Erera, who wanted to make "bad" things with addAttribute, breaking its > > behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to > prevent > > stack overflow, LUCENE-2087). They are targeted for release on 2009-11- > 25. > > > > The artifacts are here: > > http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/ > > > > You find the changes in the corresponding sub folder. The SVN revision > is > > 883080, here the manifest with build system info: > > > > Manifest-Version: 1.0 > > Ant-Version: Apache Ant 1.7.0 > > Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.) > > Specification-Title: Lucene Search Engine > > Specification-Version: 3.0.0 > > Specification-Vendor: The Apache Software Foundation > > Implementation-Title: org.apache.lucene > > Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49 > > Implementation-Vendor: The Apache Software Foundation > > X-Compile-Source-JDK: 1.5 > > X-Compile-Target-JDK: 1.5 > > > > Please vote to officially release these artifacts as "Apache Lucene Java > > 3.0.0". > > > > We need at least 3 binding (PMC) votes. > > > > Thanks everyone for all their hard work on this and I am very sorry for > > requesting a vote again, but that's life! Thanks Shai for the pointer to > the > > bug! > > > > > > > > > > Here is the proposed release note, please edit, if needed: > > ------------------------------------------------------------------------ > -- > > > > Hello Lucene users, > > > > On behalf of the Lucene dev community (a growing community far larger > than > > just the committers) I would like to announce the release of Lucene Java > > 3.0: > > > > The new version is mostly a cleanup release without any new features. > All > > deprecations targeted to be removed in version 3.0 were removed. If you > are > > upgrading from version 2.9.1 of Lucene, you have to fix all deprecation > > warnings in your code base to be able to recompile against this version. > > > > This is the first Lucene release with Java 5 as a minimum requirement. > The > > API was cleaned up to make use of Java 5's generics, varargs, enums, and > > autoboxing. New users of Lucene are advised to use this version for new > > developments, because it has a clean, type safe new API. Upgrading users > can > > now remove unnecessary casts and add generics to their code, too. If you > > have not upgraded your installation to Java 5, please read the file > > JRE_VERSION_MIGRATION.txt (please note that this is not related to > Lucene > > 3.0, it will also happen with any previous release when you upgrade your > > Java environment). > > > > Lucene 3.0 has some changes regarding compressed fields: 2.9 already > > deprecated compressed fields; support for them was removed now. Lucene > 3.0 > > is still able to read indexes with compressed fields, but as soon as > merges > > occur or the index is optimized, all compressed fields are decompressed > and > > converted to Field.Store.YES. Because of this, indexes with compressed
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Andi Vajda 2009-11-25, 16:10
On Nov 25, 2009, at 1:46, "Uwe Schindler" <[EMAIL PROTECTED]> wrote: > I would really not see this as a real test failure. The test assumes > that a > compound file index is slower during indexing, which is normally so. > But > maybe the scheduler of your O/S did something strange at the time > the test > ran and made it take longer to index without compound file. Is it > reproducible? > > In my opinion, the test is invalid, it just shows something that > happens > most of the time, but asserting it is wrong. > > I looked at the Java Version of the test: > http://java.codefetch.com/example/in/LuceneInAction/src/lia/indexing/Compoun > dVersusMultiFileIndexTest.java Yes, that is correct. The assertion is a little optimistic. Its failure can be ignored. Andi.. > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [EMAIL PROTECTED] > > >> -----Original Message----- >> From: Helmut Jarausch [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, November 25, 2009 10:33 AM >> To: [EMAIL PROTECTED] >> Cc: Andi Vajda >> Subject: Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) >> >> On 24 Nov, Andi Vajda wrote: >>> I built PyLucene trunk using Lucene Java source from the >>> artifact's svn >> rev >>> and all unit tests and ported "Lucene in Action" tests pass. >>> >>> +1 ! >>> >>> Andi.. >> >> Many thanks, Andi. >> >> Here (AMD64, python-2.6.4) a single test fails >> java development with ant: 0.502968132496 >> junit in action: 0.812919199467 >> 0.812919199467: JUnit in Action >> 0.502968132496: Java Development with Ant >> /usr/bin/python samples/LuceneInAction/ >> CompoundVersusMultiFileIndexTest.py >> F >> === >> ==================================================================>> FAIL: testTiming >> (lia.indexing.CompoundVersusMultiFileIndexTest.CompoundVersusMultiFileInde >> xTest) >> --- >> ------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/Work1/Obj/Python/pylucene- >> build/samples/LuceneInAction/lia/indexing/ >> CompoundVersusMultiFileIndexTest >> .py", line 62, in testTiming >> self.assert_(cTiming > mTiming) >> AssertionError >> >> >> Hopefully, this isn't critical. >> What could be the reason? >> >> Thanks again, >> Helmut. >> >> -- >> Helmut Jarausch >> >> Lehrstuhl fuer Numerische Mathematik >> RWTH - Aachen University >> D 52056 Aachen, Germany
-
Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)Helmut Jarausch 2009-11-26, 10:15
On 25 Nov, Uwe Schindler wrote:
> I would really not see this as a real test failure. The test assumes that a > compound file index is slower during indexing, which is normally so. But > maybe the scheduler of your O/S did something strange at the time the test > ran and made it take longer to index without compound file. Is it > reproducible? I don't know. But it's a quad core machine, perhaps something is done in parallel. Helmut. > > In my opinion, the test is invalid, it just shows something that happens > most of the time, but asserting it is wrong. > > I looked at the Java Version of the test: > http://java.codefetch.com/example/in/LuceneInAction/src/lia/indexing/Compoun > dVersusMultiFileIndexTest.java > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [EMAIL PROTECTED] > > >> -----Original Message----- >> From: Helmut Jarausch [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, November 25, 2009 10:33 AM >> To: [EMAIL PROTECTED] >> Cc: Andi Vajda >> Subject: Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) >> >> On 24 Nov, Andi Vajda wrote: >> > I built PyLucene trunk using Lucene Java source from the artifact's svn >> rev >> > and all unit tests and ported "Lucene in Action" tests pass. >> > >> > +1 ! >> > >> > Andi.. >> >> Many thanks, Andi. >> >> Here (AMD64, python-2.6.4) a single test fails >> java development with ant: 0.502968132496 >> junit in action: 0.812919199467 >> 0.812919199467: JUnit in Action >> 0.502968132496: Java Development with Ant >> /usr/bin/python samples/LuceneInAction/CompoundVersusMultiFileIndexTest.py >> F >> =====================================================================>> FAIL: testTiming >> (lia.indexing.CompoundVersusMultiFileIndexTest.CompoundVersusMultiFileInde >> xTest) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/Work1/Obj/Python/pylucene- >> build/samples/LuceneInAction/lia/indexing/CompoundVersusMultiFileIndexTest >> .py", line 62, in testTiming >> self.assert_(cTiming > mTiming) >> AssertionError >> >> >> Hopefully, this isn't critical. >> What could be the reason? >> >> Thanks again, >> Helmut. >> >> -- >> Helmut Jarausch >> >> Lehrstuhl fuer Numerische Mathematik >> RWTH - Aachen University >> D 52056 Aachen, Germany > -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany |