RE: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java

2009-10-22 Thread Uwe Schindler
Done!

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


> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Thursday, October 22, 2009 11:39 AM
> To: java-dev@lucene.apache.org
> Subject: Re: svn commit: r828334 -
> /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luc
> ene/index/TestCheckIndex.java
> 
> OK let's do first!
> 
> Mike
> 
> On Thu, Oct 22, 2009 at 5:31 AM, Uwe Schindler  wrote:
> >> Putting the LUCENE_VERSION in front of the string instead of in back
> seems
> >> fine?
> >
> > I would prefer this, as it makes it possible to do compareTo()
> comparisons
> > and so on, which may be used in client code, too (not only test). OK,
> client
> > code should not use trunk versions from Hudson, but it would be better.
> >
> >> Or we could relax the test to simply assert that the expected version
> >> appears anywhere as a substring?  (ie, .contains instead of
> >> .startsWith)
> >
> > This would only fix this test. I prefer the first.
> >
> > Uwe
> >
> >> Mike
> >>
> >> On Thu, Oct 22, 2009 at 4:13 AM, Uwe Schindler  wrote:
> >> > I found a solution for this problem!
> >> >
> >> > First the explaination:
> >> > The test CheckIndexTest compares the version numbers from Constants
> with
> >> the
> >> > current compilation (ant settings). There are two constants
> >> > Constants.LUCENE_MAIN_VERSION which is hard coded into
> Constants.java.
> >> This
> >> > version had  a problem, because it was a static final String
> constant,
> >> which
> >> > is inlined by javac, so that code compiled against that version of
> the
> >> class
> >> > file will always see the static string even when you replace the JAR.
> >> >
> >> > The second constant LUCENE_VERSION contains the same like in the
> >> manifest,
> >> > and if no manifest is available (no JAR file at all), it contains the
> >> > LUCENE_MAIN_VERSION constant. The code has some intelligence to add
> >> > LUCENE_MAIN_VERSION also to this constant (but at the end and in []
> >> > brackets), if the string from the manifest contains no version.
> >> >
> >> > E.g. Hudson compiles Lucene and puts just a date code into the
> manifest
> >> > ("-Dversion=200910" ANT parameter). LUCENE_MAIN_VERSION will
> >> contains
> >> > this string, bud as "3.0-dev" does not appear in this string, it is
> >> appended
> >> > as "[3.0-dev]".
> >> >
> >> > The test CheckIndex checks these version and tests if LUCENE_VERSION
> >> starts
> >> > with LUCENE_MAIN_VERSION, which is not correct in this case. The test
> >> works
> >> > for trunk, because the tests are run without JAR file (against the
> class
> >> > files direct), but not for backwards (as the test is run against the
> >> > lucene-core.jar, which contains the manifest).
> >> >
> >> > The easy fix would be to change Constants.LUCENE_VERSION to not
> append
> >> the
> >> > string, but places it in front of the manifest string, if the
> manifest
> >> > string does not start with LUCENE_MAIN_VERSION. We could also fix
> >> Hudson,
> >> > but then test will fail if somebody uses a strange version string
> when
> >> > calling ANT. The first solution is 100% secure.
> >> >
> >> > Opinions?
> >> >
> >> > -
> >> > Uwe Schindler
> >> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >> > http://www.thetaphi.de
> >> > eMail: u...@thetaphi.de
> >> >
> >> >> -Original Message-
> >> >> From: uschind...@apache.org [mailto:uschind...@apache.org]
> >> >> Sent: Thursday, October 22, 2009 9:22 AM
> >> >> To: java-comm...@lucene.apache.org
> >> >> Subject: svn commit: r828334 -
> >> >>
> >>
> /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luc
> >> >> ene/index/TestCheckIndex.java
> >> >>
> >> >> Author: uschindler
> >> >> Date: Thu Oct 22 07:22:28 2009
> >> >> New Revision: 828334
> >> >>
> >> >> URL: http://svn.apache.org/viewvc?rev=828334&view=rev
> >> >> Log:
> >> >> this test fails on hudson because of the strange "version" ant
> >> parameter
> >> >> with only a date code. test-tag is run against the JAR version,
> test-
> >> core
> >> >> against the class files. The JAR version contains the strange
> version
> >> >> number in manifest :(
> >> >> Should be somehow fixed. For now, I disable the test.
> >> >>
> >> >> Modified:
> >> >>
> >> >>
> >>
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> >> >> ne/index/TestCheckIndex.java
> >> >>
> >> >> Modified:
> >> >>
> >>
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> >> >> ne/index/TestCheckIndex.java
> >> >> URL:
> >> >>
> >>
> http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_9_back_compat_t
> >> >>
> >>
> ests/src/test/org/apache/lucene/index/TestCheckIndex.java?rev=828334&r1=82
> >> >> 8333&r2=828334&view=diff
> >> >>
> >>
> ==
> >> >> 
> >> >> ---
> >> >>
> >>
> lucene/java/branches/lucene_

Re: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java

2009-10-22 Thread Michael McCandless
OK let's do first!

Mike

On Thu, Oct 22, 2009 at 5:31 AM, Uwe Schindler  wrote:
>> Putting the LUCENE_VERSION in front of the string instead of in back seems
>> fine?
>
> I would prefer this, as it makes it possible to do compareTo() comparisons
> and so on, which may be used in client code, too (not only test). OK, client
> code should not use trunk versions from Hudson, but it would be better.
>
>> Or we could relax the test to simply assert that the expected version
>> appears anywhere as a substring?  (ie, .contains instead of
>> .startsWith)
>
> This would only fix this test. I prefer the first.
>
> Uwe
>
>> Mike
>>
>> On Thu, Oct 22, 2009 at 4:13 AM, Uwe Schindler  wrote:
>> > I found a solution for this problem!
>> >
>> > First the explaination:
>> > The test CheckIndexTest compares the version numbers from Constants with
>> the
>> > current compilation (ant settings). There are two constants
>> > Constants.LUCENE_MAIN_VERSION which is hard coded into Constants.java.
>> This
>> > version had  a problem, because it was a static final String constant,
>> which
>> > is inlined by javac, so that code compiled against that version of the
>> class
>> > file will always see the static string even when you replace the JAR.
>> >
>> > The second constant LUCENE_VERSION contains the same like in the
>> manifest,
>> > and if no manifest is available (no JAR file at all), it contains the
>> > LUCENE_MAIN_VERSION constant. The code has some intelligence to add
>> > LUCENE_MAIN_VERSION also to this constant (but at the end and in []
>> > brackets), if the string from the manifest contains no version.
>> >
>> > E.g. Hudson compiles Lucene and puts just a date code into the manifest
>> > ("-Dversion=200910" ANT parameter). LUCENE_MAIN_VERSION will
>> contains
>> > this string, bud as "3.0-dev" does not appear in this string, it is
>> appended
>> > as "[3.0-dev]".
>> >
>> > The test CheckIndex checks these version and tests if LUCENE_VERSION
>> starts
>> > with LUCENE_MAIN_VERSION, which is not correct in this case. The test
>> works
>> > for trunk, because the tests are run without JAR file (against the class
>> > files direct), but not for backwards (as the test is run against the
>> > lucene-core.jar, which contains the manifest).
>> >
>> > The easy fix would be to change Constants.LUCENE_VERSION to not append
>> the
>> > string, but places it in front of the manifest string, if the manifest
>> > string does not start with LUCENE_MAIN_VERSION. We could also fix
>> Hudson,
>> > but then test will fail if somebody uses a strange version string when
>> > calling ANT. The first solution is 100% secure.
>> >
>> > Opinions?
>> >
>> > -
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> > http://www.thetaphi.de
>> > eMail: u...@thetaphi.de
>> >
>> >> -Original Message-
>> >> From: uschind...@apache.org [mailto:uschind...@apache.org]
>> >> Sent: Thursday, October 22, 2009 9:22 AM
>> >> To: java-comm...@lucene.apache.org
>> >> Subject: svn commit: r828334 -
>> >>
>> /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luc
>> >> ene/index/TestCheckIndex.java
>> >>
>> >> Author: uschindler
>> >> Date: Thu Oct 22 07:22:28 2009
>> >> New Revision: 828334
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=828334&view=rev
>> >> Log:
>> >> this test fails on hudson because of the strange "version" ant
>> parameter
>> >> with only a date code. test-tag is run against the JAR version, test-
>> core
>> >> against the class files. The JAR version contains the strange version
>> >> number in manifest :(
>> >> Should be somehow fixed. For now, I disable the test.
>> >>
>> >> Modified:
>> >>
>> >>
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> >> ne/index/TestCheckIndex.java
>> >>
>> >> Modified:
>> >>
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> >> ne/index/TestCheckIndex.java
>> >> URL:
>> >>
>> http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_9_back_compat_t
>> >>
>> ests/src/test/org/apache/lucene/index/TestCheckIndex.java?rev=828334&r1=82
>> >> 8333&r2=828334&view=diff
>> >>
>> ==
>> >> 
>> >> ---
>> >>
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> >> ne/index/TestCheckIndex.java (original)
>> >> +++
>> >>
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> >> ne/index/TestCheckIndex.java Thu Oct 22 07:22:28 2009
>> >> @@ -96,6 +96,8 @@
>> >>      assertNotNull(version);
>> >>      assertTrue(version.equals(Constants.LUCENE_MAIN_VERSION+"-dev") ||
>> >>                 version.equals(Constants.LUCENE_MAIN_VERSION));
>> >> -    assertTrue(Constants.LUCENE_VERSION.startsWith(version));
>> >> +    // TODO: does not work on hudson, because tests are run against a
>> JAR
>> >> version,
>> >> +    // which has a package version like "20091013*" not "3.0*":
>> >> +    //assert

RE: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java

2009-10-22 Thread Uwe Schindler
> Putting the LUCENE_VERSION in front of the string instead of in back seems
> fine?

I would prefer this, as it makes it possible to do compareTo() comparisons
and so on, which may be used in client code, too (not only test). OK, client
code should not use trunk versions from Hudson, but it would be better.

> Or we could relax the test to simply assert that the expected version
> appears anywhere as a substring?  (ie, .contains instead of
> .startsWith)

This would only fix this test. I prefer the first.

Uwe

> Mike
> 
> On Thu, Oct 22, 2009 at 4:13 AM, Uwe Schindler  wrote:
> > I found a solution for this problem!
> >
> > First the explaination:
> > The test CheckIndexTest compares the version numbers from Constants with
> the
> > current compilation (ant settings). There are two constants
> > Constants.LUCENE_MAIN_VERSION which is hard coded into Constants.java.
> This
> > version had  a problem, because it was a static final String constant,
> which
> > is inlined by javac, so that code compiled against that version of the
> class
> > file will always see the static string even when you replace the JAR.
> >
> > The second constant LUCENE_VERSION contains the same like in the
> manifest,
> > and if no manifest is available (no JAR file at all), it contains the
> > LUCENE_MAIN_VERSION constant. The code has some intelligence to add
> > LUCENE_MAIN_VERSION also to this constant (but at the end and in []
> > brackets), if the string from the manifest contains no version.
> >
> > E.g. Hudson compiles Lucene and puts just a date code into the manifest
> > ("-Dversion=200910" ANT parameter). LUCENE_MAIN_VERSION will
> contains
> > this string, bud as "3.0-dev" does not appear in this string, it is
> appended
> > as "[3.0-dev]".
> >
> > The test CheckIndex checks these version and tests if LUCENE_VERSION
> starts
> > with LUCENE_MAIN_VERSION, which is not correct in this case. The test
> works
> > for trunk, because the tests are run without JAR file (against the class
> > files direct), but not for backwards (as the test is run against the
> > lucene-core.jar, which contains the manifest).
> >
> > The easy fix would be to change Constants.LUCENE_VERSION to not append
> the
> > string, but places it in front of the manifest string, if the manifest
> > string does not start with LUCENE_MAIN_VERSION. We could also fix
> Hudson,
> > but then test will fail if somebody uses a strange version string when
> > calling ANT. The first solution is 100% secure.
> >
> > Opinions?
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >> -Original Message-
> >> From: uschind...@apache.org [mailto:uschind...@apache.org]
> >> Sent: Thursday, October 22, 2009 9:22 AM
> >> To: java-comm...@lucene.apache.org
> >> Subject: svn commit: r828334 -
> >>
> /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luc
> >> ene/index/TestCheckIndex.java
> >>
> >> Author: uschindler
> >> Date: Thu Oct 22 07:22:28 2009
> >> New Revision: 828334
> >>
> >> URL: http://svn.apache.org/viewvc?rev=828334&view=rev
> >> Log:
> >> this test fails on hudson because of the strange "version" ant
> parameter
> >> with only a date code. test-tag is run against the JAR version, test-
> core
> >> against the class files. The JAR version contains the strange version
> >> number in manifest :(
> >> Should be somehow fixed. For now, I disable the test.
> >>
> >> Modified:
> >>
> >>
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> >> ne/index/TestCheckIndex.java
> >>
> >> Modified:
> >>
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> >> ne/index/TestCheckIndex.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_9_back_compat_t
> >>
> ests/src/test/org/apache/lucene/index/TestCheckIndex.java?rev=828334&r1=82
> >> 8333&r2=828334&view=diff
> >>
> ==
> >> 
> >> ---
> >>
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> >> ne/index/TestCheckIndex.java (original)
> >> +++
> >>
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> >> ne/index/TestCheckIndex.java Thu Oct 22 07:22:28 2009
> >> @@ -96,6 +96,8 @@
> >>      assertNotNull(version);
> >>      assertTrue(version.equals(Constants.LUCENE_MAIN_VERSION+"-dev") ||
> >>                 version.equals(Constants.LUCENE_MAIN_VERSION));
> >> -    assertTrue(Constants.LUCENE_VERSION.startsWith(version));
> >> +    // TODO: does not work on hudson, because tests are run against a
> JAR
> >> version,
> >> +    // which has a package version like "20091013*" not "3.0*":
> >> +    //assertTrue(Constants.LUCENE_VERSION.startsWith(version));
> >>    }
> >>  }
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: java-dev-unsubscr...@lucen

Re: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java

2009-10-22 Thread Michael McCandless
Putting the LUCENE_VERSION in front of the string instead of in back seems fine?

Or we could relax the test to simply assert that the expected version
appears anywhere as a substring?  (ie, .contains instead of
.startsWith)

Mike

On Thu, Oct 22, 2009 at 4:13 AM, Uwe Schindler  wrote:
> I found a solution for this problem!
>
> First the explaination:
> The test CheckIndexTest compares the version numbers from Constants with the
> current compilation (ant settings). There are two constants
> Constants.LUCENE_MAIN_VERSION which is hard coded into Constants.java. This
> version had  a problem, because it was a static final String constant, which
> is inlined by javac, so that code compiled against that version of the class
> file will always see the static string even when you replace the JAR.
>
> The second constant LUCENE_VERSION contains the same like in the manifest,
> and if no manifest is available (no JAR file at all), it contains the
> LUCENE_MAIN_VERSION constant. The code has some intelligence to add
> LUCENE_MAIN_VERSION also to this constant (but at the end and in []
> brackets), if the string from the manifest contains no version.
>
> E.g. Hudson compiles Lucene and puts just a date code into the manifest
> ("-Dversion=200910" ANT parameter). LUCENE_MAIN_VERSION will contains
> this string, bud as "3.0-dev" does not appear in this string, it is appended
> as "[3.0-dev]".
>
> The test CheckIndex checks these version and tests if LUCENE_VERSION starts
> with LUCENE_MAIN_VERSION, which is not correct in this case. The test works
> for trunk, because the tests are run without JAR file (against the class
> files direct), but not for backwards (as the test is run against the
> lucene-core.jar, which contains the manifest).
>
> The easy fix would be to change Constants.LUCENE_VERSION to not append the
> string, but places it in front of the manifest string, if the manifest
> string does not start with LUCENE_MAIN_VERSION. We could also fix Hudson,
> but then test will fail if somebody uses a strange version string when
> calling ANT. The first solution is 100% secure.
>
> Opinions?
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: uschind...@apache.org [mailto:uschind...@apache.org]
>> Sent: Thursday, October 22, 2009 9:22 AM
>> To: java-comm...@lucene.apache.org
>> Subject: svn commit: r828334 -
>> /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luc
>> ene/index/TestCheckIndex.java
>>
>> Author: uschindler
>> Date: Thu Oct 22 07:22:28 2009
>> New Revision: 828334
>>
>> URL: http://svn.apache.org/viewvc?rev=828334&view=rev
>> Log:
>> this test fails on hudson because of the strange "version" ant parameter
>> with only a date code. test-tag is run against the JAR version, test-core
>> against the class files. The JAR version contains the strange version
>> number in manifest :(
>> Should be somehow fixed. For now, I disable the test.
>>
>> Modified:
>>
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> ne/index/TestCheckIndex.java
>>
>> Modified:
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> ne/index/TestCheckIndex.java
>> URL:
>> http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_9_back_compat_t
>> ests/src/test/org/apache/lucene/index/TestCheckIndex.java?rev=828334&r1=82
>> 8333&r2=828334&view=diff
>> ==
>> 
>> ---
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> ne/index/TestCheckIndex.java (original)
>> +++
>> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
>> ne/index/TestCheckIndex.java Thu Oct 22 07:22:28 2009
>> @@ -96,6 +96,8 @@
>>      assertNotNull(version);
>>      assertTrue(version.equals(Constants.LUCENE_MAIN_VERSION+"-dev") ||
>>                 version.equals(Constants.LUCENE_MAIN_VERSION));
>> -    assertTrue(Constants.LUCENE_VERSION.startsWith(version));
>> +    // TODO: does not work on hudson, because tests are run against a JAR
>> version,
>> +    // which has a package version like "20091013*" not "3.0*":
>> +    //assertTrue(Constants.LUCENE_VERSION.startsWith(version));
>>    }
>>  }
>>
>
>
>
> -
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>

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



RE: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java

2009-10-22 Thread Uwe Schindler
I found a solution for this problem!

First the explaination:
The test CheckIndexTest compares the version numbers from Constants with the
current compilation (ant settings). There are two constants
Constants.LUCENE_MAIN_VERSION which is hard coded into Constants.java. This
version had  a problem, because it was a static final String constant, which
is inlined by javac, so that code compiled against that version of the class
file will always see the static string even when you replace the JAR.

The second constant LUCENE_VERSION contains the same like in the manifest,
and if no manifest is available (no JAR file at all), it contains the
LUCENE_MAIN_VERSION constant. The code has some intelligence to add
LUCENE_MAIN_VERSION also to this constant (but at the end and in []
brackets), if the string from the manifest contains no version.

E.g. Hudson compiles Lucene and puts just a date code into the manifest
("-Dversion=200910" ANT parameter). LUCENE_MAIN_VERSION will contains
this string, bud as "3.0-dev" does not appear in this string, it is appended
as "[3.0-dev]".

The test CheckIndex checks these version and tests if LUCENE_VERSION starts
with LUCENE_MAIN_VERSION, which is not correct in this case. The test works
for trunk, because the tests are run without JAR file (against the class
files direct), but not for backwards (as the test is run against the
lucene-core.jar, which contains the manifest).

The easy fix would be to change Constants.LUCENE_VERSION to not append the
string, but places it in front of the manifest string, if the manifest
string does not start with LUCENE_MAIN_VERSION. We could also fix Hudson,
but then test will fail if somebody uses a strange version string when
calling ANT. The first solution is 100% secure.

Opinions?

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

> -Original Message-
> From: uschind...@apache.org [mailto:uschind...@apache.org]
> Sent: Thursday, October 22, 2009 9:22 AM
> To: java-comm...@lucene.apache.org
> Subject: svn commit: r828334 -
> /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luc
> ene/index/TestCheckIndex.java
> 
> Author: uschindler
> Date: Thu Oct 22 07:22:28 2009
> New Revision: 828334
> 
> URL: http://svn.apache.org/viewvc?rev=828334&view=rev
> Log:
> this test fails on hudson because of the strange "version" ant parameter
> with only a date code. test-tag is run against the JAR version, test-core
> against the class files. The JAR version contains the strange version
> number in manifest :(
> Should be somehow fixed. For now, I disable the test.
> 
> Modified:
> 
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> ne/index/TestCheckIndex.java
> 
> Modified:
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> ne/index/TestCheckIndex.java
> URL:
> http://svn.apache.org/viewvc/lucene/java/branches/lucene_2_9_back_compat_t
> ests/src/test/org/apache/lucene/index/TestCheckIndex.java?rev=828334&r1=82
> 8333&r2=828334&view=diff
> ==
> 
> ---
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> ne/index/TestCheckIndex.java (original)
> +++
> lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/luce
> ne/index/TestCheckIndex.java Thu Oct 22 07:22:28 2009
> @@ -96,6 +96,8 @@
>  assertNotNull(version);
>  assertTrue(version.equals(Constants.LUCENE_MAIN_VERSION+"-dev") ||
> version.equals(Constants.LUCENE_MAIN_VERSION));
> -assertTrue(Constants.LUCENE_VERSION.startsWith(version));
> +// TODO: does not work on hudson, because tests are run against a JAR
> version,
> +// which has a package version like "20091013*" not "3.0*":
> +//assertTrue(Constants.LUCENE_VERSION.startsWith(version));
>}
>  }
> 



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