Re: HSQLDB / Unit tests

On 09/23/2013 09:19 AM, Andrzej Hunt wrote:
> I'm trying to get HSQLDB unit tests to run in a CppunitTest -- whilst
> still in solver I added some paths locally to solver's unorc (which
> worked fine, but not a great solution) -- now that we're running unit
> tests in instdir I'd like some sort of permanent solution. (The reason I
> want to use a CppUnitTest is that ideally we want to run exactly the
> same tests on Firebird and HSQLDB, and since that also allows for
> performance comparisons.)
>
> HSQLDB's classpath is hardcoded in HDriver.cxx as:
> vnd.sun.star.expand:$BRAND_BASE_DIR/" LIBO_SHARE_JAVA_FOLDER
> "/hsqldb.jar"
> As a first step I'd like to make this:
> vnd.sun.star.expand:$LO_JAVA_DIR/hsqldb.jar
>
> Either of these work when running LO normally, the latter is cleaner and
> seems much more correct. (Patch is in gerrit, but outdated commit
> comment now that we're in instdir --
> https://gerrit.libreoffice.org/#/c/5953/ ).

The patch is just fine in itself anyway, so I pushed it now.

> However neither of these work for unit tests: BRAND_BASE_DIR and
> LO_JAVA_DIR are both set in fundamentalrc, which doesn't seem to be used
> when running unit tests. It also looks like when running unit tests only
> the ure/lib/unorc is used -- I'm not entirely sure how to procede here
> -- using LO_JAVA_DIR within HSQLDB setting
> LO_JAVA_DIR=${ORIGIN}/../../program/classes
> works, but is that the desired way of doing things (adjusted by using
> scp2 I guess to work on all systems)?

There are two things that tie all the bootstrap variables together:

The first is the uno{.ini,rc} file next to the cppuhelper dynamic 
library, automatically read by the default, no-argument 
cppu::defaultBootstrap_InitialComponentContext 
(cppuhelper/source/defaultbootstrap.cxx) to bootstrap URE in any 
application process.  It sets those bootstrap variables necessary for 
URE itself (and independent of any specific application like LO's 
soffice).  Historically, there are two instances of the cppuhelper 
dynamic library, and consequently two instances of accompanying 
uno{.ini,rc} (with different content): one in solver for the tools run 
during the build---which in the past used to include cppunittester that 
runs the CppunitTests---and one in instdir and installation sets---which 
is now used also by cppunittester, which might be a change not 
thought-through enough yet (see below).

The other is the URE_BOOTSTRAP bootstrap variable, normally set via 
tools::extendApplicationEnvironment 
(tools/source/misc/extendapplicationenvironment.cxx; called from 
application start-up code like soffice_main, 
desktop/source/app/sofficemain.cxx, and unopkg_main, 
desktop/source/pkgchk/unopkg/unopkg_app.cxx) to point to the 
fundamental{.ini,rc} next to the application's executable.  The 
program/fundamental{.ini,rc} in turn contains most bootstrap variables 
you'll ever encounter (incl. LO_JAVA_DIR; for mostly historic reasons, 
it offloads some variables to an additional uno{.ini,rc} next to itself 
that can content-wise be considered an ini-file on of the above URE uno 
ini-file).

The ideal with the recent move to instdir would of course be to run 
CppunitTests against instdir (as the---premature?---move of 
cppunittester to instdir manifests).  However, one caveat I already 
mentioned elsewhere "that comes to mind with running tests against 
instdir instead of solver is that the [old] setup makes sure that any 
JRE used by the tests is the one configured --with-jdk-home (by making 
use of jvmfwk's 'direct mode'), not one found via the jvmfwk search 
mechanisms.  Another caveat is that should any of those tests 
'accidentally' make use of bootstrap{rc,.ini}s UserInstallation, we 
should override that to make sure those tests do not interfere with the 
user's configuration."

Yet another caveat is that those CppunitTests can run against varyingly 
"filled" instdirs, and thus behave subtly differently should they ever 
start to pick up the various bootstrap variables defined across instdir 
(which reference stuff in instdir that might or might not yet be there).

Therefore, it is a good thing that solenv/gbuild/CppunitTest.mk still 
defines the relevant bootstrap variables manually.  So, all that might 
be necessary for you now is

> diff --git a/solenv/gbuild/CppunitTest.mk b/solenv/gbuild/CppunitTest.mk
> index 1f9390f..154841f 100644
> --- a/solenv/gbuild/CppunitTest.mk
> +++ b/solenv/gbuild/CppunitTest.mk
> @@ -61,6 +61,7 @@ $(if $(URE),\
>         "-env:UNO_SERVICES=$(foreach item,$(UNO_SERVICES),$(call gb_Helper_make_url,$(item)))") \
>         -env:URE_INTERNAL_LIB_DIR=$(call gb_Helper_make_url,$(INSTROOT)/$(LIBO_URE_LIB_FOLDER)) \
>         -env:LO_LIB_DIR=$(call gb_Helper_make_url,$(INSTROOT)/$(gb_PROGRAMDIRNAME)) \
> +       -env:LO_JAVA_DIR=$(call gb_Helper_make_url,$(INSTROOT)/$(LIBO_SHARE_JAVA_FOLDER)) \
>         --protector $(call gb_Library_get_target,unoexceptionprotector) unoexceptionprotector \
>         --protector $(call gb_Library_get_target,unobootstrapprotector) unobootstrapprotector \
>   ) $(ARGS)

---let me know if that patch would make your test work.

Stephan