lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: Tests, Contribs, and Releases
Date Sat, 19 May 2007 06:49:13 GMT

On Fri, 18 May 2007, Chris Hostetter wrote:

> Even if we get the neccessary native lib installed on the lucene zone for
> nightly builds, that doesn't really help in the case of official releases
> where a release manager builds locally -- assuming the tests are fine
> because the nightly buidls are fine isn't relaly a good policy, since
> releases may be on a patch branch with no nightly build.
> From a unit testing purist standpoint, the unit tests for contrib/db/bdb
> wouldn't require the native lib at all -- they would use a mock API to
> simyulate the real API so that there were no dependencies (native or
> otherwise) ... other "integration tests" could be optional and require the
> ral native lib to run successfully.
> I have no idea how hard it would be to mock out the BDB API, but
> personally I'd settle for a clean way to gracefully skip the
> contrib/db/bdb tests if the lib isn't available  (much the way the build
> system skips contrib/gdata-server if java 1.5 is not available).
> I don't really know enough about JNI however to know how to do this ...
> the best idea i have is to try and catch these exceptions in the test --
> but if we just ignore them then the test stats would give the false
> impression that they passed -- what we really need is a way for ant to
> know that the native lib isn't available, and skip the tests in that case.

If the Runtime.loadLibrary() API can load the bdb native library, the tests 
should be run, else they should be skipped with a warning. [1]

> i suppose we could just define bdb test target to only run if some new
> "test.contrib.db.bdb" property is set -- and if not, echo a big fat
> wraning anytime anyone attempts to run the test.




To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message