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

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]

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

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

+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

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

> 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

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

+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]

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]

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

+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

+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]
>
>
>

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

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

+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

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]

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]

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

> 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

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

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:

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

> 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

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

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

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

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
>

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

+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!

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

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

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