Mailing List Archive: Lucene: General

[VOTE] Release Apache Lucene Java 3.0.0 (take #2)

Index | Next | Previous | View Threaded

uwe at thetaphi

Nov 22, 2009, 7:07 AM

Post #1 of 16 (1925 views)
Permalink

[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
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: uwe [at] thetaphi

uwe at thetaphi

Nov 22, 2009, 1:23 PM

Post #2 of 16 (1888 views)
Permalink

RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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: uwe [at] thetaphi

> -----Original Message-----
> From: Uwe Schindler [mailto:uwe [at] thetaphi]
> Sent: Sunday, November 22, 2009 4:07 PM
> To: general [at] lucene; java-dev [at] lucene
> 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
> 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: uwe [at] thetaphi
>

uwe at thetaphi

Nov 22, 2009, 1:41 PM

Post #3 of 16 (1887 views)
Permalink

RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

> 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:uwe [at] thetaphi]
> > Sent: Sunday, November 22, 2009 4:07 PM
> > To: general [at] lucene; java-dev [at] lucene
> > 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
> > 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: uwe [at] thetaphi
> >
>

yeahyf at gmail

Nov 22, 2009, 7:56 PM

Post #4 of 16 (1885 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

+1

2009/11/23 Uwe Schindler <uwe [at] thetaphi>

> > 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:uwe [at] thetaphi]
> > > Sent: Sunday, November 22, 2009 4:07 PM
> > > To: general [at] lucene; java-dev [at] lucene
> > > 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
> > > 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: uwe [at] thetaphi
> > >
> >
>
>
>

uwe at thetaphi

Nov 23, 2009, 11:26 PM

Post #5 of 16 (1870 views)
Permalink

RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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: uwe [at] thetaphi

> -----Original Message-----
> From: Uwe Schindler [mailto:uwe [at] thetaphi]
> Sent: Sunday, November 22, 2009 4:07 PM
> To: general [at] lucene; java-dev [at] lucene
> 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
> 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: uwe [at] thetaphi
>

lucene at mikemccandless

Nov 24, 2009, 2:01 AM

Post #6 of 16 (1863 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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 <uwe [at] thetaphi> 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: uwe [at] thetaphi
>
>> -----Original Message-----
>> From: Uwe Schindler [mailto:uwe [at] thetaphi]
>> Sent: Sunday, November 22, 2009 4:07 PM
>> To: general [at] lucene; java-dev [at] lucene
>> 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
>> 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: uwe [at] thetaphi
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
> For additional commands, e-mail: java-dev-help [at] lucene
>
>

uwe at thetaphi

Nov 24, 2009, 2:09 AM

Post #7 of 16 (1862 views)
Permalink

RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

> 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 <uwe [at] thetaphi> 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: uwe [at] thetaphi
> >
> >> -----Original Message-----
> >> From: Uwe Schindler [mailto:uwe [at] thetaphi]
> >> Sent: Sunday, November 22, 2009 4:07 PM
> >> To: general [at] lucene; java-dev [at] lucene
> >> 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
> >> 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: uwe [at] thetaphi
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
> > For additional commands, e-mail: java-dev-help [at] lucene
> >
> >

vajda at apache

Nov 24, 2009, 8:10 PM

Post #8 of 16 (1856 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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..

jarausch at igpm

Nov 25, 2009, 1:32 AM

Post #9 of 16 (1858 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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

uwe at thetaphi

Nov 25, 2009, 1:46 AM

Post #10 of 16 (1856 views)
Permalink

RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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: uwe [at] thetaphi

> -----Original Message-----
> From: Helmut Jarausch [mailto:jarausch [at] igpm]
> Sent: Wednesday, November 25, 2009 10:33 AM
> To: general [at] lucene
> 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

lucene at mikemccandless

Nov 25, 2009, 1:47 AM

Post #11 of 16 (1857 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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
<jarausch [at] igpm> 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
>

uwe at thetaphi

Nov 25, 2009, 6:51 AM

Post #12 of 16 (1846 views)
Permalink

RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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: uwe [at] thetaphi

> -----Original Message-----
> From: Uwe Schindler [mailto:uwe [at] thetaphi]
> Sent: Sunday, November 22, 2009 4:07 PM
> To: general [at] lucene; java-dev [at] lucene
> 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
> 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: uwe [at] thetaphi
>

gsingers at apache

Nov 25, 2009, 6:53 AM

Post #13 of 16 (1846 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

+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.
>
> --------------------------------------------------------------------------
>
>
>
> Thanks,
> Uwe
>
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe [at] thetaphi
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
> For additional commands, e-mail: java-dev-help [at] lucene
>

uwe at thetaphi

Nov 25, 2009, 7:09 AM

Post #14 of 16 (1852 views)
Permalink

RE: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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: uwe [at] thetaphi

> -----Original Message-----
> From: Grant Ingersoll [mailto:gsingers [at] apache]
> Sent: Wednesday, November 25, 2009 3:54 PM
> To: java-dev [at] lucene
> Cc: general [at] lucene
> 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
> > 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: uwe [at] thetaphi
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
> > For additional commands, e-mail: java-dev-help [at] lucene
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
> For additional commands, e-mail: java-dev-help [at] lucene

vajda at apache

Nov 25, 2009, 8:10 AM

Post #15 of 16 (1853 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

On Nov 25, 2009, at 1:46, "Uwe Schindler" <uwe [at] thetaphi> 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: uwe [at] thetaphi
>
>
>> -----Original Message-----
>> From: Helmut Jarausch [mailto:jarausch [at] igpm]
>> Sent: Wednesday, November 25, 2009 10:33 AM
>> To: general [at] lucene
>> 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

jarausch at igpm

Nov 26, 2009, 2:15 AM

Post #16 of 16 (1831 views)
Permalink

Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) [In reply to]

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: uwe [at] thetaphi
>
>
>> -----Original Message-----
>> From: Helmut Jarausch [mailto:jarausch [at] igpm]
>> Sent: Wednesday, November 25, 2009 10:33 AM
>> To: general [at] lucene
>> 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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads