db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Upgrade tests and jars in the repository
Date Wed, 05 Apr 2006 21:26:13 GMT
I've been thinking about how to make the Derby jars accessible to the
upgrade tests, and I don't think there's going to be a better way
other than to put the jars into the repository. But, I don't think we
should check them into the code tree. I think that we should create a
new tree at the same level as code, site, and docs, and call it jars.
In this tree will be directories containing the Derby jars from the
official releases in directories by version. E.g.:

derby
+ code
+ jars
    + 10.1.1.0
    + 10.1.2.1

Then, we can map the specific jars we need into the code tree using
the svn:externals property to a specific location in the code tree, I
suggest tools/testing/derby/{version}. This way, we prevent lots of
copies of the derby jars from multiplying in the repository as
branches are created and tagged. Yeah, I know, they're lazy copies not
real copies, but it seems a lot cleaner way to do it to me. It also
makes changing the jars in your view as simple as changing/adding a
property if you want to test against a different set of jars.

This does mean that you'll need to download a set of Derby jars with
each new checkout, adding to the space, time, and bandwidth
requirements to checkout. As an alternative, I had also thought about
having Ant grab the jars on demand, but that seemed less intuitive
than having svn grab them automatically. And, we do want everybody
running the upgrade tests, right?

Deepa, does this sound like a good plan to you? Will the upgrade tests
be able to locate the jars in the location above? That's the next
question to answer and I'll start looking at how the tests can locate
the jars based on the execution environment.

andrew

Mime
View raw message