[ 
https://issues.apache.org/jira/browse/LUCENE-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-5190:
----------------------------------

    Attachment: LUCENE-5190.patch

This should fix the bug. This only affects clover builds because the following:
- The hourly Jenkins builds don't change the version string, because artifacts 
are not archived, Javadocs are also not archived (its just heavy testing)
- The nightly Artifact builds change the version to contain the Jenkins Build 
Timestamp/Build Number. But when building nightly artifacts we don't run tests, 
so this is not triggered
- The Clover builds run tests, but they have to change the build number like 
the nightly artifact builds, because the version number is part of the archived 
artifacts (in that case the Clover HTML pages). So those should contain (like 
Javadocs) a build number.

We should change this to not only allow "-SNAPSHOT", but instead allow any 
version that is equal to expected build version or has anything starting with 
"-" appended.

This would allow others also to build and run artifacts with customized 
versions, like "Lucene 4.5.0-dfsg-ubuntu1" (for the Debian guys among us).

The patch changes the assert to allow this.
                
> Consistent failure of TestCheckIndex.testLuceneConstantVersion in jenkins 
> trunk clover build
> --------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-5190
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5190
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Hoss Man
>            Assignee: Uwe Schindler
>         Attachments: LUCENE-5190.patch
>
>
> I'm out of the loop on how clover is run, and how the build system sets up th 
> version params, but looking at the coverage reports i noticed that the trunk 
> clover build seems to have been failing consistently for a while -- some 
> sporadic test failures, but one consistent failure smells like it has to do 
> with a build configuration problem...
> {noformat}
> java.lang.AssertionError: Invalid version: 5.0-2013-08-11_15-22-48
>       at 
> __randomizedtesting.SeedInfo.seed([648EC34D8642C547:A7103483A05D2588]:0)
>       at org.junit.Assert.fail(Assert.java:93)
>       at org.junit.Assert.assertTrue(Assert.java:43)
>       at 
> org.apache.lucene.index.TestCheckIndex.__CLR3_1_10l79zdz2ior(TestCheckIndex.java:132)
>       at 
> org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestCheckIndex.java:118)
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to