On 4/10/06, Deepa Remesh (JIRA) <[email protected]> wrote:
>
> > Integrate upgrade tests into test suite
> > ---------------------------------------
> >
> > Key: DERBY-514
> > URL: http://issues.apache.org/jira/browse/DERBY-514
> > Project: Derby
> > Type: Test
JIRA's not letting me add comments right now, so here are the comments
I was going to add to DERBY-514 re: Deepa's patch3.
Hi Deepa,
Patch3 looks pretty good, but a few minor comments:
- instead of hardcoding the relative path tools/testing/derby in the
JAR_RELATIVE_PATH variable, I think it would just be better to let the
user specify the actual directory the older jar directories will be
in. That provides a more flexible way to specify the location of the
derby jars for those who will be running automated tests with just the
jars on remote machines.
- in the build file there is this:
+ <target name="updateproperty" if="derbyTesting.jar.path">
+ <propertyfile
file="${out.dir}/${derby.testing.functest.dir}/tests/upgradeTests/Upgrade_10_1_10_2_app.properties">
+ <entry key="jvmflags"
value="-DderbyTesting.jar.path=${derbyTesting.jar.path}" />
+ </propertyfile>
+ </target>
Instead of relying on the user to set ${derbyTesting.jar.path}, you
could just use ${basedir}/tools/testing/derby. That is, unless the
intention is to allow the user to place the jars anywhere, and just
once, on their machine. In which case, not having that hardcoded
relative path would again be nice, as then the jars could be placed
practically anywhere, with few restrictions. If the idea is to enforce
a location relative to the local subversion view by setting
svn:externals, then it seems like a better idea to set the path
relative to ${basedir}. I'm not real keen on putting a local path into
a properties file in derbyTesting.jar that only has meaning on the
machine where it is built, but it does make it convenient for
verifying results on your own dev machine. I also don't have any other
briliiant ideas for handling the case where the jars are now running
on another machine either. (jar up the necessary derby jars into
another jar to distribute for testing? seems so heavyweight...)
- Also, better error handling when loading from classes, not jars, as
Kathey mentioned earlier, and also if the jars are not found in
derbyTesting.jar.path, would be nice. Currently, if the jars aren't
where the property says they would be, I get this error:
> java.lang.reflect.InvocationTargetException
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/services/info/JVMInfo
By the way, is there any intention to allow loading the new classes
from a classes directory and not just the jars?
thanks,
andrew
