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.
Yep. Andi.. [1] http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#loadLibrary(java.lang.String) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
