db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Upgrade tests and jars in the repository
Date Wed, 05 Apr 2006 22:19:54 GMT
I often have multiple checkouts on my machine, one for something I'm 
running derbyall, one for something I'm actively working on, and one for 
patches I need to evaluate.

I don't think it's crucial, but is there a way to have a single set of 
jar files that can be shared across multiple code checkouts?  Is that 
what you are making possible by changing the svn:externals property?


Andrew McIntyre wrote:
> 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
>     +
>     +
> 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

View raw message