> > and setting the version number as stated in the release howto to "3.1- > dev" > > for the future builds (which are not working at the moment because node > > down). > > Done.
Thanks! > > The svn dir "nightly" was already changed. > > > I'm not following L-1769. Is there an action to take there or not? I > only skimmed it, but it seems like there are still some questions. I'm > not sure why it is a big deal to run the stuff twice. While it will be > faster, who cares? That stuff runs at night on our zone. That is not the real problem of the issue, it was just a suggestion during my investigations. The problem is more, that the current version of clover running on Lucene Java's Hudson build is so old and has problems with correctly detecting the backwards-compatibility tests. Because of that, the clover reports only show the test-tag tests in core. You see no coverage of contrib and no coverage of new tests added (because they are in core). This old clover version has no ant task properties to fix that, it just uses the first test it found (which are the backwards tests, because they seem to "fit better" in clovers eyes). You can easily see this, if you search for the last Lucene 2.9 build before switch to 3.0/3.1 and look into the clover report: NumericRangeQuery has no coverage, but a test exists (because the test-tag does not test it); the same for all new classes for per-segment search. Even today 3.0/3.1, you can see no coverage for contrib tests. But NRQ/segment-search is covered now, because we use 2.9 tests for test-tag. I changed the build.xml and already discussed with Nick Pellow from Atlassian about a license for the latest version that can also be shipped together with the lucene jars. To get a better insight on the whole Hudson build process I wanted to start to look close into directory structure and so on inside the whole build job and find out how to solve this elegant. Because of that I wanted to get a Hudson account. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
