RE: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java
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=828334view=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=828334r1=82 8333r2=828334view=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
Re: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java
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 u...@thetaphi.de 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=828334view=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=828334r1=82 8333r2=828334view=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
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 u...@thetaphi.de 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=828334view=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=828334r1=82 8333r2=828334view=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:
Re: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java
OK let's do first! Mike On Thu, Oct 22, 2009 at 5:31 AM, Uwe Schindler u...@thetaphi.de 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 u...@thetaphi.de 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=828334view=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=828334r1=82 8333r2=828334view=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,
RE: svn commit: r828334 - /lucene/java/branches/lucene_2_9_back_compat_tests/src/test/org/apache/lucene/index/TestCheckIndex.java
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 u...@thetaphi.de 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 u...@thetaphi.de 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=828334view=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=828334r1=82 8333r2=828334view=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)); -
