Extra notes on running tests

[Daniel John Debrunner <dj...@debrunners.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


The class RunTest usually runs the actual test in another JVM, that it
is spawns a JVM to run the test. The JVM running the class RunTest is
used to manage the required files and perform the diffs and result
processing. This means that the classpath *must* be set in the
environment  and exported, like

export CLASSPATH="$jardir/derby.jar:$jardir/derbytools.jar: \
$jardir/derbyTesting.jar:/local/derby/tools/java/jakarta-oro-2.0.8.jar"


Invoking the tests by setting the classpath with a command line option
will *not* work, e.g. this will not work.

java -cp "$jardir/derby.jar:$jardir/derbytools.jar: \
$jardir/derbyTesting.jar:/local/derby/tools/java/jakarta-oro-2.0.8.jar"
 org.apache.derbyTesting.functionTests.harness.RunTest lang/supersimple.sql


In addition, in case it isn't clear, if you are just running tests
against just the embedded engine, then you do not need the network
server or JCC jar files in your classpath.


Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBlRMrIv0S4qsbfuQRAiX0AKDGaFRcTsGBpmvCP33nQ8WLq0jqlACeO1Yy
a3wFJ0W6BhdBygDeEj6CGlg=
=CV6h
-----END PGP SIGNATURE-----

Re: Extra notes on running tests

[Samuel Andrew McIntyre <fu...@nonintuitive.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 13, 2004, at 4:39 AM, Jan Hlavatý wrote:

> I suggeest we take the same approach I created for Jetty -
> have a launcher class that sets up the required classpath
> by setting up a classloader. This moves the problem of creating
> classpaths from platform specific domain to Java domain, which is
> portable.

This is an interesting idea, and having such a launcher would allow us 
to do some other nifty things like making derbyTesting.jar executable.

Also, considering the original problem that items that are passed in on 
the command line with -cp or -classpath aren't reflected in the 
classpath of the forked vm running individual tests, it should be 
possible to modify RunTest's execTestProcess method to pass the 
classpath from RunSuite/RunTest's vm to the forked vm that runs the 
actual test.

andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBnZl/DfB0XauCH7wRAtyTAJ9oATY0s5GL3oazaeC8g2aWdMMviACeJLR3
vp+Ru8nzy+5b95GseWbADzo=
=1X6u
-----END PGP SIGNATURE-----

Re: Extra notes on running tests

[Jan Hlavatý <hl...@code.cz>]

Daniel John Debrunner wrote:
 This means that the classpath *must* be set in the
> environment  and exported, like
> 
> export CLASSPATH="$jardir/derby.jar:$jardir/derbytools.jar: \
> $jardir/derbyTesting.jar:/local/derby/tools/java/jakarta-oro-2.0.8.jar"

I suggeest we take the same approach I created for Jetty -
have a launcher class that sets up the required classpath
by setting up a classloader. This moves the problem of creating
classpaths from platform specific domain to Java domain, which is
portable.
Makes managing classpath so much easier, and you can even include
different classpath components based on the running environment
(Java version, classes available on system classpath/ext, etc.).
What do you think?

Jan