On 4/5/06, Deepa Remesh <[EMAIL PROTECTED]> wrote:
>
> This is the general idea I am working on: Specify a new property
> (derby.source.path) in ant.properties file which points to the source
> files on the local machine. When building upgrade tests, this property
> will be used to create a property (derbyTesting.jarPath) in the
> <test>_app.properties file. When running the upgrade tests, the code
> looks for derbyTesting.jarPath property and adds the relative path
> (e.g: tools/testing/derby/{version}) to it and uses this as the
> location of previous release jars. With this approach, we will need
> the svn workspace (which has the previous release jars) to be on the
> machine where we run the tests.
>
> Does this sound good to you? Or do you have any other ideas?This sounds like a good direction to go, and should work right away when testing against the raw classes. With our automated tests, the jars are distributed from a build location to various test machines. I'm sure that others who do automated testing here probably do something similar. So when testing with jars we will probably want to be able to override the location in derbyTesting.jarPath with either a standard relative location or a user-specified location. Then the test machines just need to checkout the directories from db/derby/jars that they need for the upgrade tests to the standard location, or wherever they choose and set the override property. andrew
