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

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

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,

[jira] Resolved: (LUCENE-2004) Constants.LUCENE_MAIN_VERSION is inlined in code compiled against Lucene JAR, so version detection is incorrect

2009-10-22 Thread Uwe Schindler (JIRA)
[ https://issues.apache.org/jira/browse/LUCENE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-2004. --- Resolution: Fixed Fixed. > Constants.LUCENE_MAIN_VERSION is inlined in code compiled agains

<    1   2